Fedora Account System
Red Hat Associate
Red Hat Customer
I run into an issue with my Online Accounts today. I needed to revoke the Nextcloud permission and re-authenticate my account in GNOME. This normally wouldn't be a problem, you typically just wait after revocation until Online Account catches up and asks you to log in again. However, after doing so today, i.e. revoking and re-authorizing, Online Accounts showed the "Invalid password with username "..." (goa-error-quark, 4)" error. Turns out the items migrated from a gnome-keyring keyring carry the attribute xdg:content-type = application/octet-stream, meanwhile the items created by Secret Service D-Bus API now carry xdg:content-type = text/plain. The oo7 MR #549 (https://github.com/linux-credentials/oo7/pull/549, fix for #541) made it so that CreateItem(replace=true) only removes items whose attributes match exactly, so the Online Accounts, after having me re-authenticate, does *not* replace the previous entry and, instad, adds a duplicate. Now, SearchItems still uses subset matching and returns the migrated item first, so secret_password_lookup() keeps returning the stale secret, making goa-daemon return an error. Reproducible: Always Steps to Reproduce: 1. Upgrade a system to oo7 keyring 2. Revoke the account credential on the server side (e.g. in your Nextcloud or Google account profile) 3. In Settings, Online Accounts, wait until it catches up with log-in failure (or force it with pkill -x goa-daemon), then log-in again. 4. Observe that GOA still fails to authenticate. 5. Inspect the keyring Actual Results: $ secret-tool search --all xdg:schema org.gnome.OnlineAccounts | grep -E '^\[|goa-identity|content-type|created' [/48] created = 2026-09-27 23:53:43 attribute.goa-identity = owncloud:gen0:account_1770817713_0 attribute.xdg:content-type = application/octet-stream [/74] created = 2026-10-26 14:21:42 attribute.goa-identity = owncloud:gen0:account_1770817713_0 attribute.xdg:content-type = text/plain `secret-tool lookup goa-identity owncloud:gen0:account_1770817713_0` returns the secret of item 48, the migrated one. oo7-daemon log for step 3: INFO create_item{label="GOA owncloud credentials for identity account_1770817713_0" replace=true}: oo7::file::unlocked_keyring: Successfully created item INFO oo7_daemon::collection: Item `/org/freedesktop/secrets/collection/login/74` created by :1.4086 (gnome-control-center[450242]). No item is removed despite replace=true. Expected Results: CreateItem(replace=true) should replace an item that has the same client-supplied attributes. xdg:content-type is set by the service, not by the client, so it should either be excluded from the exact-match comparison, or the migration should assign the same content type that a fresh store produces. Additional Information: This was already fixed upstream in https://github.com/linux-credentials/oo7/pull/578, but hasn't been ported over to F45 nor rawhide package yet. Workaround for the time being is to delete the migrated items by hand: `secret-tool clear goa-identity owncloud:gen0:account_1770817713_0 xdg:content-type application/octet-stream` Environment: - Fedora 45, GNOME 51.1 (gnome-shell 51.1-1.fc45) - oo7-daemon 0.7.0~beta-2.fc45, oo7-portal 0.7.0~beta-2.fc45 - gnome-online-accounts 3.58.1-4.fc45, libsecret 0.21.8.2-2.fc45
Proposed as a Blocker and Freeze Exception for 45-final by Fedora user augenauf using the blocker tracking app because: Saving passwords to and retrieving passwords from the default keyring must work for all release-blocking desktops.
There's a scratch build of a git snapshot at https://koji.fedoraproject.org/koji/taskinfo?taskID=151720449 . Please test it and see if it fixes this bug, and if you notice any other problems with it. Thanks.
Adam, I am afraid I won't be able to test it truthfully, I already applied a workaround here and hand-removed the imported values.
+4 in https://forge.fedoraproject.org/quality/blocker-review/issues/2244 , marking accepted blocker.
FEDORA-2026-fd58111611 (oo7-0.7.0~beta^1.e91b98a-1.fc45) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-fd58111611
FEDORA-2026-fd58111611 has been pushed to the Fedora 45 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-fd58111611` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-fd58111611 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
So, I'm trying to reproduce/verify this (in something of a hurry), but I can't seem to get the process to quite go right. I've upgraded to F45 *with* the new oo7, and revoked the credential from the server end (I'm using Google). Apps that depend on it, e.g. Evolution, know it's now invalid, but GOA doesn't seem to. It's not indicating that I'm logged out, or anything. Even after killing goa processes, rebooting, logging out...it just seems to show it as a working account. I wonder if this is a new symptom introduced by the fix for this, or some other change in the git snapshot?
Still couldn't get GOA to recognize the account was invalid after trying various things. But I did test that simply removing the account and recreating it works fine, and I think that's a good enough state, personally.
FEDORA-2026-fd58111611 (oo7-0.7.0~beta^1.e91b98a-1.fc45) has been pushed to the Fedora 45 stable repository. If problem still persists, please make note of it in this bug report.