Package: gdm3 Version: 3.38.2.1-1 Severity: important Hi,
On LUKS-encrypted systems, by default the GNOME keyring is encrypted using the LUKS passphrase typed on boot. pam_gdm unlocks the keyring using that passphrase. So far, so good. On current sid, pam_gdm uses the _first_ passphrase that was typed on boot. So if I mistype my passphrase on the first attempt, then type it correctly, pam_gdm will use the first (wrong) passphrase, and fail to unlock my GNOME keyring. As a result, all kinds of functionality that depends on the data in my GNOME keyring are broken, e.g. Chromium saved passwords. When this happens, I'm offered to unlock my keyring. It took me some research to figure out I had to type my LUKS passphrase, as opposed for example to my login password. I expect most Debian users would not discover this solution by themselves. It took me a while to understand what was going on, and why my GNOME keyring was seemingly randomly unavailable. I expect less technical users will just give up, assume GNOME keyring is totally buggy, and stop using it. Given how broad the impact is on unrelated software, one might argue this bug could qualify as RC. The upstream fix is self-contained and seems very simple. May we consider including it in Bullseye? I suppose it depends in part on how common we expect LUKS-encrypted systems to be among Debian + GNOME users. - Upstream bug report: https://gitlab.gnome.org/GNOME/gdm/-/issues/657 - Upstream fix: https://gitlab.gnome.org/GNOME/gdm/-/merge_requests/136 - Longer story: https://github.com/systemd/systemd/issues/17565 Thanks for maintaining GNOME in Debian, Cheers!
