Bug#987298: gdm3: Fails to unlock GNOME keyring when multiple attempts were needed to unlock LUKS

intrigeri at debian.org intrigeri at debian.org
Wed Apr 21 07:33:01 BST 2021


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!



More information about the pkg-gnome-maintainers mailing list