I’ve enjoyed playing around with my L5, but I’m confused by something trying to unlock the (GNOME?) keyring at every boot. How would I determine what program that is? I don’t think it started happening until after I installed a few packages, but it’s been awhile.
Curiously, that keyring password is also different from my password for the purism user.
Geary, the mail client, will ask for the password to unlock the default keyring - but that should only happen when you launch Geary.
But without knowing what those “few packages” are it is difficult to guess.
A messenger application of some kind?
And you would need to clarify exactly which keyring you are talking about (since the Gnome environment allows you to have many different and independent keyrings).
I would regard that as de rigueur. If you are going to set the keyring password (for a particular keyring) to be equal to the purism user password then to some extent you might as well unlock the keyring automatically on login (which may not work yet on the Librem 5 but is a possibility).
I always get that message immediately after login to the L5. I haven’t even set up Geary or any other mail client on the phone since I reflashed it to byzantium, and there’s no other login set up besides the L5 itself, according to the Passwords and Keys app. But come to think of it, it must be the password for Backups, which refuses to persist.
Quite annoying to have to enter two passwords. (I’m using the same one for both.)
I don’t have any passwords prompts i think you can edit the keychain password to be blank and it will not ask. Maybe not secure, but i care mostly about convenience.
I don’t know how to do this but if you can get a screenshot that will at least tell us which keyring it is attempting to unlock, which may then give clues as to what application is requesting access to that keyring.
Yeah and I think this is a known current limitation.
I haven’t looked at any sources or anything but I think the problem is: on a regular desktop/laptop you have to log in explicitly by choosing a username and entering the password, which then can optionally unlock the login keyring using the same password via PAM, whereas on the Librem 5 that log in process never happens at all. It may be that if you can persuade the desktop manager to present that normal login screen before you actually log in then the login keyring would get unlocked.
It may also be that if you don’t care about security then you could change the login keyring password to something different from your actual purism password and run a ‘script’ at login that will unlock the login keyring explicitly using a plaintext exposed password. (That wouldn’t be obscenely terrible if you are using encryption on the root partition, which I suppose most Librem 5 customers are?)
I can see easily that the WiFi passphrase is stored in plaintext. So there shouldn’t be a need to unlock a keyring in order to associate with WiFi.
Would I prefer in fact that you are correct? Maybe so. That is, it isn’t great security that a WiFi passphrase is stored in plaintext (understanding that that is “plaintext on an encrypted file system”).
However there is a thorny chicken-and-egg problem with getting the WiFi passphrase out of a keyring. Suppose that you need to unlock a keyring in order to access WiFi. That’s fine. But then suppose that you need to access WiFi in order to log in in the first place. (There may be ways round that e.g. some kind of system keyring, separate from a user keyring.)
Now in the Librem 5 environment (most likely single user and unlikely to be using distributed account information and not technically requiring authentication to log in at boot up anyway) that probably isn’t an issue.
Similarly, in some customer environments, it may be painful that WiFi isn’t available until after you have unlocked. For example, it means that if you run any network services on your phone, those services simply won’t work until after you have unlocked. So there are some other dependencies besides the simple act of logging in.
This would be doubly painful if you have somehow broken the GUI but connecting in via SSH would actually work and allow you to fix the GUI (… if only you could unlock the GUI in order to unlock the keyring in order to associate with WiFi so that SSH can function).
However if you have an OpenPGP card, it may be even better to trigger, or allow, a cascade of unlocking by successfully opening the OpenPGP card - depending on your security requirements - and if/when that becomes a standard option.