Bug 2356002

I am seeing something similar in fedora 41. Seems that something is changing the password of the login.keyring outside of the normal pam process (at least, its not logging anything). I created a post for my troubleshooting steps here:

https://discourse.gnome.org/t/troubleshooting-no-longer-matches-that-of-your-login-keyring-problem/29019

The main idea is that something is changing the password, but its not being logged

```
# journalctl --since "2025-05-01 00:00:00" --until "2025-05-20 23:59:59" --no-pager | grep -i "gkr-pam"
May 02 20:50:38 pc04 gdm-password][6384]: gkr-pam: unable to locate daemon control file
May 02 20:50:38 pc04 gdm-password][6384]: gkr-pam: stashed password to try later in open session
May 02 20:50:39 pc04 gdm-password][6384]: gkr-pam: gnome-keyring-daemon started properly and unlocked keyring
May 09 23:18:10 pc04 gdm-password][3000]: gkr-pam: unable to locate daemon control file
May 09 23:18:10 pc04 gdm-password][3000]: gkr-pam: stashed password to try later in open session
May 09 23:18:10 pc04 gdm-password][3000]: gkr-pam: gnome-keyring-daemon started properly and unlocked keyring
May 10 01:28:29 pc04 gdm-password][2888]: gkr-pam: unable to locate daemon control file
May 10 01:28:29 pc04 gdm-password][2888]: gkr-pam: stashed password to try later in open session
May 10 01:28:29 pc04 gdm-password][2888]: gkr-pam: gnome-keyring-daemon started properly and unlocked keyring
#
```

perusal of the code, suggests that it should log something if it was changed during a pam passwd change <https://gitlab.gnome.org/GNOME/gnome-keyring/-/blob/main/pam/gkr-pam-module.c?ref_type=heads#L733-748>

```
	res = gkr_pam_client_run_operation (pwd, control, GKD_CONTROL_OP_CHANGE, 2, argv);
	if (res == GKD_CONTROL_RESULT_NO_DAEMON) {
		if (need_daemon)
			*need_daemon = 1;
		return PAM_SERVICE_ERR;
	/* No keyring, not an error. Will be created at initial authenticate. */
	} else if (res == GKD_CONTROL_RESULT_DENIED) {
		syslog (GKR_LOG_ERR, "gkr-pam: couldn't change password for the login keyring: the passwords didn't match.");
		return PAM_SERVICE_ERR;
	} else if (res != GKD_CONTROL_RESULT_OK) {
		syslog (GKR_LOG_ERR, "gkr-pam: couldn't change password for the login keyring.");
		return PAM_SERVICE_ERR;
	}
	syslog (GKR_LOG_NOTICE, "gkr-pam: changed password for login keyring");
	return PAM_SUCCESS;
```

There is a report from back in 2023, with similar details:
<https://discussion.fedoraproject.org/t/keyring-password-changed-without-me-knowing/78160/9>

```
$ sudo file /home/.snapshots/{804,813,824,830,851}/snapshot/user/.local/share/keyrings/login.keyring
/home/.snapshots/804/snapshot/user/.local/share/keyrings/login.keyring: GNOME keyring, major version 0, minor version 0, crypto type 0 (AES), hash type 0 (MD5), name "Login", last modified Tue Oct 18 16:39:50 2022, created Thu Jan  1 00:00:00 1970, not locked if idle, hash iterations 2639, salt 5671152323367239619, 6 item(s)
/home/.snapshots/813/snapshot/user/.local/share/keyrings/login.keyring: GNOME keyring, major version 0, minor version 0, crypto type 0 (AES), hash type 0 (MD5), name "Login", last modified Thu Jan  1 00:00:00 1970, created Tue Oct 18 16:39:50 2022, not locked if idle, hash iterations 2596, salt 11579539427720780673, 6 item(s)
/home/.snapshots/824/snapshot/user/.local/share/keyrings/login.keyring: GNOME keyring, major version 0, minor version 0, crypto type 0 (AES), hash type 0 (MD5), name "Login", last modified Thu Jan  1 00:00:00 1970, created Tue Oct 18 16:39:50 2022, not locked if idle, hash iterations 2596, salt 11579539427720780673, 6 item(s)
/home/.snapshots/830/snapshot/user/.local/share/keyrings/login.keyring: GNOME keyring, major version 0, minor version 0, crypto type 0 (AES), hash type 0 (MD5), name "Login", last modified Thu Jan  1 00:00:00 1970, created Tue Oct 18 16:39:50 2022, not locked if idle, hash iterations 1415, salt 6381053758584472797, 6 item(s)
/home/.snapshots/851/snapshot/user/.local/share/keyrings/login.keyring: GNOME keyring, major version 0, minor version 0, crypto type 0 (AES), hash type 0 (MD5), name "Login", last modified Tue Oct 18 16:39:50 2022, created Thu Jan  1 00:00:00 1970, not locked if idle, hash iterations 1489, salt 10434400876941994071, 6 item(s)

...
> Keyrings from snapshots 813, 824, and 830 are not decryptable.
```


But from my experience, the daemon has the keyring open the whole time, and is writing out changes. for example for me

```
39278|login.keyring|6fWrQoKY/AsNZs+hICejlA|E9F5AB428298FC0B0D66CFA12027A394|39281|2025-05-17 19:30:05.000|2025-05-17 20:30:05.000|
39177|login.keyring|xhQNMloukmi/PzPFlR8rbA|C6140D325A2E9268BF3F33C5951F2B6C|39275|2025-05-16 18:30:04.000|2025-05-17 18:30:05.000|
39174|login.keyring|6uTeSu/K1nNaIOEzO7cihQ|EAE4DE4AEFCAD6735A20E1333BB72285|39174|2025-05-16 17:30:04.000|2025-05-16 17:30:04.000|
39165|login.keyring|OAqrXwvVHxUTBiule6E1jQ|380AAB5F0BD51F1513062BA57BA1358D|39165|2025-05-16 16:30:04.000|2025-05-16 16:30:04.000|
39156|login.keyring|by57hCtuA4S3N0lsQYcU3A|6F2E7B842B6E0384B737496C418714DC|39162|2025-05-16 13:30:05.000|2025-05-16 15:30:04.000|
39141|login.keyring|8qToBfuCmQbh/hFT+aFp+g|F2A4E805FB829906E1FE1153F9A169FA|39153|2025-05-16 10:30:05.000|2025-05-16 12:30:05.000|
39135|login.keyring|X33acJ9opDRPupgAt6Luvw|5F7DDA709F68A4344FBA9800B7A2EEBF|39138|2025-05-16 08:30:05.000|2025-05-16 09:30:05.000|
38571|login.keyring|lkFS7HR6u7aN7/ffVYqukg|964152EC747ABBB68DEFF7DF558AAE92|39132|2025-05-10 14:30:05.000|2025-05-16 07:30:05.000|
```

so it seems that the password that gkr daemon has in memory, and is writing out to these intermediate backups, is actually corrupt/changed, same as the user above. That is there are no more gkr-pam logs in journal between any of those writes of login.keyring, so it must be coming from the daemon (my hypotheis, anyway)

ah ok, this is what i was looking for

```
$ journalctl --utc --user  | grep gnome-keyring-daemon |  grep 'May 10'
May 10 06:39:45 pc04 gnome-keyring-daemon[3310]: discover_other_daemon: 1
May 10 06:39:45 pc04 gnome-keyring-daemon[209976]: discover_other_daemon: 0
May 10 06:39:45 pc04 gnome-keyring-daemon[209976]: Replacing daemon, using directory: /run/user/1000/keyring
May 10 06:39:45 pc04 gnome-keyring-daemon[209976]: failed to unlock login keyring on startup
May 10 13:51:14 pc04 gnome-keyring-daemon[209976]: couldn't allocate secure memory to keep passwords and or keys from being written to the disk
May 10 13:51:14 pc04 gnome-keyring-daemon[209976]: fixed login keyring password to match login password
May 10 14:26:28 pc04 gnome-keyring-daemon[209976]: asked to register item /org/freedesktop/secrets/collection/login/1271, but it's already registered
May 10 14:28:06 pc04 gnome-keyring-daemon[921417]: discover_other_daemon: 0
May 10 14:28:06 pc04 gnome-keyring-daemon[921417]: Replacing daemon, using directory: /run/user/1000/keyring
```

```
May 10 13:51:14 pc04 gnome-keyring-daemon[209976]: fixed login keyring password to match login password
````

the backup produced at 14:30, can't be decrypted any more, so this is likely what did it.

so further analysis of that incident above, I am seeing that something is prompting for a password, which appears to timeout


```

May 10 13:51:06 pc04 systemd[2901]: Started dbus-:1.2-org.gnome.keyring.SystemPrompter.
May 10 13:51:06 pc04 gcr-prompter[747530]: GLib-GIO: Using cross-namespace EXTERNAL authentication (this will deadlock if server is GDBus < 2.73.3)
May 10 13:51:06 pc04 gcr-prompter[747530]: Gcr: bus acquired: org.gnome.keyring.SystemPrompter
May 10 13:51:06 pc04 gcr-prompter[747530]: Gcr: registering prompter
May 10 13:51:06 pc04 gcr-prompter[747530]: Gcr: bus acquired: org.gnome.keyring.PrivatePrompter
May 10 13:51:06 pc04 gcr-prompter[747530]: Gcr: acquired name: org.gnome.keyring.SystemPrompter
May 10 13:51:06 pc04 gcr-prompter[747530]: Gcr: received BeginPrompting call from callback /org/gnome/keyring/Prompt/p3@:1.804
May 10 13:51:06 pc04 gcr-prompter[747530]: Gcr: preparing a prompt for callback /org/gnome/keyring/Prompt/p3@:1.804
May 10 13:51:06 pc04 gcr-prompter[747530]: Gcr: creating new GcrPromptDialog prompt
May 10 13:51:06 pc04 gcr-prompter[747530]: GLib-GIO: _g_io_module_get_default: Found default implementation gvfs (GDaemonVfs) for ‘gio-vfs’
May 10 13:51:06 pc04 /usr/libexec/gdm-x-session[2975]: (--) NVIDIA(GPU-0): DFP-0: disconnected
...
May 10 13:51:06 pc04 /usr/libexec/gdm-x-session[2975]: (--) NVIDIA(GPU-0):
May 10 13:51:06 pc04 gcr-prompter[747530]: Gcr: automatically selecting secret exchange protocol
May 10 13:51:06 pc04 gcr-prompter[747530]: Gcr: generating public key
May 10 13:51:06 pc04 gcr-prompter[747530]: Gcr: beginning the secret exchange: [sx-aes-1]\npublic=Un9ecVQXgNHAxzP6Oc...
May 10 13:51:06 pc04 gcr-prompter[747530]: Gcr: calling the PromptReady method on /org/gnome/keyring/Prompt/p3@:1.804
May 10 13:51:06 pc04 gcr-prompter[747530]: Gcr: acquired name: org.gnome.keyring.PrivatePrompter
May 10 13:51:06 pc04 gcr-prompter[747530]: Gcr: returned from the PromptReady method on /org/gnome/keyring/Prompt/p3@:1.804
May 10 13:51:06 pc04 gcr-prompter[747530]: Gcr: received PerformPrompt call from callback /org/gnome/keyring/Prompt/p3@:1.804
May 10 13:51:06 pc04 gcr-prompter[747530]: Gcr: receiving secret exchange: [sx-aes-1]\npublic=E9MJh25xAY76bxALIVw...
May 10 13:51:06 pc04 gcr-prompter[747530]: Gcr: deriving shared transport key
May 10 13:51:06 pc04 gcr-prompter[747530]: Gcr: deriving transport key
May 10 13:51:06 pc04 gcr-prompter[747530]: Gcr: starting password prompt for callback /org/gnome/keyring/Prompt/p3@:1.804
May 10 13:51:06 pc04 /usr/libexec/gdm-x-session[2975]: (--) NVIDIA(GPU-0): Idek Iiyama PLX2783H (DFP-6): connected
...
May 10 13:51:06 pc04 /usr/libexec/gdm-x-session[2975]: (--) NVIDIA(GPU-0):
May 10 13:51:14 pc04 gcr-prompter[747530]: Gcr: completed password prompt for callback :1.804@/org/gnome/keyring/Prompt/p3
May 10 13:51:14 pc04 gcr-prompter[747530]: Gcr: encrypting data
May 10 13:51:14 pc04 gcr-prompter[747530]: Gcr: sending the secret exchange: [sx-aes-1]\npublic=Un9ecVQXgNHAxzP...
May 10 13:51:14 pc04 gcr-prompter[747530]: Gcr: calling the PromptReady method on /org/gnome/keyring/Prompt/p3@:1.804
May 10 13:51:14 pc04 gnome-keyring-daemon[209976]: couldn't allocate secure memory to keep passwords and or keys from being written to the disk
May 10 13:51:14 pc04 gcr-prompter[747530]: Gcr: returned from the PromptReady method on /org/gnome/keyring/Prompt/p3@:1.804
May 10 13:51:14 pc04 gnome-keyring-daemon[209976]: fixed login keyring password to match login password
May 10 13:51:14 pc04 gcr-prompter[747530]: Gcr: received PerformPrompt call from callback /org/gnome/keyring/Prompt/p3@:1.804
May 10 13:51:14 pc04 gcr-prompter[747530]: Gcr: stopping prompting for operation /org/gnome/keyring/Prompt/p3@:1.804
May 10 13:51:14 pc04 gcr-prompter[747530]: Gcr: closing the prompt
May 10 13:51:14 pc04 gcr-prompter[747530]: Gcr: stopping prompting for operation /org/gnome/keyring/Prompt/p3@:1.804
May 10 13:51:14 pc04 gcr-prompter[747530]: Gcr: couldn't find the callback for prompting operation /org/gnome/keyring/Prompt/p3@:1.804
May 10 13:51:14 pc04 gcr-prompter[747530]: Gcr: stopping prompting for operation /org/gnome/keyring/Prompt/p3@:1.804
May 10 13:51:14 pc04 gcr-prompter[747530]: Gcr: couldn't find the callback for prompting operation /org/gnome/keyring/Prompt/p3@:1.804
May 10 13:51:14 pc04 gcr-prompter[747530]: Gcr: stopping prompting for operation /org/gnome/keyring/Prompt/p3@:1.804
May 10 13:51:14 pc04 gcr-prompter[747530]: Gcr: couldn't find the callback for prompting operation /org/gnome/keyring/Prompt/p3@:1.804
May 10 13:51:14 pc04 gcr-prompter[747530]: Gcr: calling the PromptDone method on /org/gnome/keyring/Prompt/p3@:1.804, and ignoring reply
May 10 13:51:24 pc04 gcr-prompter[747530]: Gcr: 10 second inactivity timeout, quitting
May 10 13:51:24 pc04 gcr-prompter[747530]: Gcr: unregistering prompter
May 10 13:51:24 pc04 gcr-prompter[747530]: Gcr: disposing prompter
May 10 13:51:24 pc04 gcr-prompter[747530]: Gcr: finalizing prompter
```

and this is triggering this <https://gitlab.gnome.org/GNOME/gnome-keyring/-/blob/main/pkcs11/wrap-layer/gkm-wrap-prompt.c?ref_type=heads#L724-780>

```
static void
fix_login_keyring_if_unlock_failed (GkmWrapPrompt *self, const gchar *password)
{
	CK_OBJECT_CLASS klass = CKO_G_CREDENTIAL;
	CK_OBJECT_HANDLE cred;
	CK_BBOOL tval = CK_TRUE;
	CK_ATTRIBUTE attrs[4];
	gchar *failed;
	CK_RV rv;

	failed = gkm_wrap_login_steal_failed_password ();

	/* Do we have a failed unlock password? */
	if (!failed || !failed[0]) {
		egg_secure_strfree (failed);
		return;
	}

	attrs[0].type = CKA_CLASS;
	attrs[0].pValue = &klass;
	attrs[0].ulValueLen = sizeof (klass);

	attrs[1].type = CKA_VALUE;
	attrs[1].pValue = failed;
	attrs[1].ulValueLen = strlen (failed);

	attrs[2].type = CKA_GNOME_TRANSIENT;
	attrs[2].pValue = &tval;
	attrs[2].ulValueLen = sizeof (tval);

	attrs[3].type = CKA_TOKEN;
	attrs[3].pValue = &tval;
	attrs[3].ulValueLen = sizeof (tval);

	/* Create a credential object for the failed password */
	rv = (self->module->C_CreateObject) (self->session, attrs, G_N_ELEMENTS (attrs), &cred);
	egg_secure_strfree (failed);

	if (rv != CKR_OK) {
		g_warning ("couldn't create credential to fix login password: %s",
		           gkm_log_rv (rv));
		return;
	}

	attrs[0].type = CKA_G_CREDENTIAL;
	attrs[0].pValue = &cred;
	attrs[0].ulValueLen = sizeof (cred);

	/* Set the credential on the object */
	rv = (self->module->C_SetAttributeValue) (self->session, self->object, attrs, 1);
	if (rv != CKR_OK) {
		g_warning ("couldn't change credential to fix login keyring password: %s",
		           gkm_log_rv (rv));
		return;
	}

	g_message ("fixed login keyring password to match login password");
}
```


It's not clear what the password would be being set to under these circumstances. It doesn't seem to be an empty string, as I tried decrypting the 14:30 backup (the first one taken following this event) and it doesn't work.

The consequence seems to be that this occasional behaviour is causing the login.keyring to be encrypted with an unknown (to me anyway) password.

It hardly needs pointing out, but the fact that the keyring is unlocked and responding to requests for secrets, despite having written a  (probably) unrecoverable login.keyring to disk doesn't show up until the user attempts to re-open the keyring, which in my case was a 11 days later. So any secrets stored in that time are lost. Indeed, if you aren't backing up the login.keyring, then all your login.keyring secrets are unrecoverable and lost.

It's not a particularly rare event either, I see lots of reports of similar behaviour

User Farzad_K reports "Login keyring password "no longer matches" in Nov 3, 2017
<https://askubuntu.com/questions/972350/login-keyring-password-no-longer-matches>

Similar question in Mar 2018
<https://superuser.com/questions/1301437/getting-a-your-password-no-longer-matches-your-keyring-error-when-i-try-to-acc>

And a bit of searching reveals many more, with the solution being "delete your login.keyring" and start again, which seem ridiculous.

ok, to test what the password was set to, i got claude to make this test file to try a bunch of common passwords: <https://github.com/tolland/gnome-keyring/blob/806e52e28eae975cf20f591a5839638d5e9c6de3/pkcs11/secret-store/test-login-keyring-passwords.c#L86>


this produces output like so

```
/home/user/git/gnome/gnome-keyring/buildDir/pkcs11/secret-store/login-keyring-passwords
TAP version 14
# random seed: R02Sa59b9735b5186326df38e0275431b562
1..6
# Start of secret-store tests
# Start of login-keyring tests
# Testing login.keyring with various passwords...
# LOCKED: Password 'password' failed to unlock keyring
# LOCKED: Password '123456' failed to unlock keyring
# LOCKED: Password 'password123' failed to unlock keyring
# LOCKED: Password 'admin' failed to unlock keyring
...
# LOCKED: Password 'debian' failed to unlock keyring
# LOCKED: Password 'redhat' failed to unlock keyring
# LOCKED: Password 'centos' failed to unlock keyring
# LOCKED: Password '' failed to unlock keyring
# LOCKED: Password ' ' failed to unlock keyring
# SUCCESS: Password '
# ' unlocked the keyring
```

so the password is being set to a newline