Bug 2068010
| Summary: | Turn runtime warnings around libsecret into debug prints | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | VIRENDRASINGH RAJPUT <vrajput> |
| Component: | gnome-online-accounts | Assignee: | Milan Crha <mcrha> |
| Status: | CLOSED ERRATA | QA Contact: | Michal Odehnal <modehnal> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 8.5 | CC: | jraising, mcrha, modehnal, ndegraef, sbarcomb, tpopela, vpakolu |
| Target Milestone: | rc | Keywords: | Triaged |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | gnome-online-accounts-3.28.2-4.el8 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-05-16 08:13:31 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
VIRENDRASINGH RAJPUT
2022-03-24 09:32:47 UTC
We definitely won't allow the GNOME Online Software to be disabled and removed from the system as its an integral part of it (and definitely not in RHEL 8 nor in RHEL 9 due to that). We should look at fixing the warning instead, I see it has been reported in Fedora as well in https://bugzilla.redhat.com/show_bug.cgi?id=1753129 . Rishi, would you mind to take a look at this bug? I will dig into this in the coming weeks. I believe that I had looked into it in the past, but ran out of time to fix it. It's very likely a problem inside libsecret and gnome-keyring. I investigated the fedora bz this weekend (see my last comment there) and it seems it's probably GOA having some mismatches on the strings it uses to lookup passwords in libsecret (In reply to Debarshi Ray from comment #3) > I will dig into this in the coming weeks. I believe that I had looked into > it in the past, but ran out of time to fix it. > > It's very likely a problem inside libsecret and gnome-keyring. I finally managed to dig up my notes from the past. It used to be quite a popular bug in the past: https://bugzilla.gnome.org/show_bug.cgi?id=765406 However, I think that's not the same as this one. Sorry about that. I briefly looked into the sources around that journal entry and, from my point of view, it's only a debug print on the goa side. The documentation says it's perfectly valid to have returned NULL from the secret_password_lookup_sync(), it means the required secret was not found in the keyring. That will turn the GOA account into "needs attention" state, which means the user needs to re-login to the server in the Settings->Online Accounts. I just proposed upstream [1] a change to turn the runtime warnings into the debug prints, because that's what they really are. [1] https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/merge_requests/96 (In reply to Niels De Graef from comment #4) > I investigated the fedora bz this weekend (see my last comment there) and it > seems it's probably GOA having some mismatches on the strings it uses to > lookup passwords in libsecret Being this true, it's another story, but I do not see it here (it may not mean much, if I did not catch the right circumstances). I can reproduce the runtime warning by deleting the GOA keys from the keyring (for example in seahorse). I guess it's unlikely the customer erased his/her keys, or maybe the whole keyring, after he/she configured the GOA account. ========================================================================== Vishal, could you ask the customer to open Settings->Online Accounts and check what accounts he/she has configured there, please? If I'm not mistaken, there might be one using OAuth2, possibly a Google account. Having no accounts configured in there will stop spamming the journal, because this print is related to one of the configured accounts. Could he/she also check whether the account requires an attention? It's indicated in the Settings, the account has a warning icon on the on the right of its name and when the account is clicked, the account properties show a notice and a request to "Sign in". If unsure, the ~/.config/goa-1.0/accounts.conf contains a list of the configured accounts. Do not share it anywhere, it's only a place to look at. The following command can show what account types are configured, without leaking any private information about the account address itself: $ cat ~/.config/goa-1.0/accounts.conf | grep Provider= If they do not want to use the Online Accounts then they should not define accounts there at the first place. One tricky part is Kerberos, I think GOA adds "accounts" for that on its own. What I asked for above was to verify my guesses are right. Without that they are only guesses and nothing else. Nonetheless, the upstream approved the changes at [1]. It can be backported to RHEL. [1] https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/merge_requests/96 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (gnome-online-accounts bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2023:2746 |