#270 made linux-keyutils the default credential builder on Linux in order to resolve errors for users who do not have gnome-keyring installed. However, unlike gnome-keyring, linux-keyutils does not persist credentials on disk. They are stored in kernel memory only, are lost on reboot, and also time out after a configurable period of non-use. linux-keyutils is designed primarily around the needs of cloud-based virtual machine instances which themselves have no persistence and are provisioned at boot by some sort of key distribution server. It isn't a good fit for dev desktops, or at least not on its own.
There's no free lunch here, really. If credentials are going to survive across reboots, they need to be stored on disk somewhere. If they're stored in plaintext, that has the obvious security drawbacks, and there's no advantage to using the keyring crate at all rather than just using the filesystem. If they're stored encrypted, then the decryption key has to come from somewhere, so either you have to prompt for a password or it has to be already available from an agent, in which case the agent has to get it from somewhere. If you want decryption to appear seamless, then the only good option is to derive the key from the user's login password at the time of login, which is exactly what gnome-keyring does. But that can only work if the system is set up for it, having gnome-keyring installed and pam_keyring configured. So basically, you're going to have to choose between:
- Storing keys in plaintext, or
- Needing to prompt for a password at least sometimes,
- Requiring some system infrastructure which isn't universally available,
- Giving up on persistence altogether and requiring the user to regularly repeat the authorization workflow.
Ideally, you'd pick a sensible default (probably 3, maybe 2), but make it configurable.
#270 made
linux-keyutilsthe default credential builder on Linux in order to resolve errors for users who do not havegnome-keyringinstalled. However, unlikegnome-keyring,linux-keyutilsdoes not persist credentials on disk. They are stored in kernel memory only, are lost on reboot, and also time out after a configurable period of non-use.linux-keyutilsis designed primarily around the needs of cloud-based virtual machine instances which themselves have no persistence and are provisioned at boot by some sort of key distribution server. It isn't a good fit for dev desktops, or at least not on its own.There's no free lunch here, really. If credentials are going to survive across reboots, they need to be stored on disk somewhere. If they're stored in plaintext, that has the obvious security drawbacks, and there's no advantage to using the
keyringcrate at all rather than just using the filesystem. If they're stored encrypted, then the decryption key has to come from somewhere, so either you have to prompt for a password or it has to be already available from an agent, in which case the agent has to get it from somewhere. If you want decryption to appear seamless, then the only good option is to derive the key from the user's login password at the time of login, which is exactly whatgnome-keyringdoes. But that can only work if the system is set up for it, havinggnome-keyringinstalled andpam_keyringconfigured. So basically, you're going to have to choose between:Ideally, you'd pick a sensible default (probably 3, maybe 2), but make it configurable.