[systemd-devel] Keyring service as a natural use-case for systemd?

[Lennart Poettering]

On Wed, 25.06.14 14:25, Anatol Pomozov (anatol.pomozov at gmail.com) wrote:

Haya,

> One of the weirdest decisions made by ssh/gpg developers is using
> environment variables to pass information about agent processes. Why
> don't they use some well-known location for the socket file like any
> other application does? Currently I need to run the *-agent daemon
> from user account, construct environment variables and propagate it to
> other processes such as Gnome and terminals started by sshd.service.
> It would be much nicer if *-agents created
> /run/user/$uid/gpg-agent.socket that any program can use.

Well, $XDG_RUNTIME_DIR is relatively young, and gpg/ssh are not. Also,
the BSDs don't really have that. env vars are really awful for what they
are doing, but then again, i'd fault UNIX for that, not
them. $XDG_RUNTIME_DIR is simply our way to fix UNIX in this regard.

> But I would love to see just one system daemon for all users without
> the additional configuration steps. All I expect to start the service
> is:
> 
> sudo systemctl enable systemd-keyringd.socket
> 
> After that 'ssh' 'gpg' should work without any configuration hustle.

So, my strong suggestion would be that everything should just use the
kernel keyring (as in keyctl(1)), and then gnome-keyring-daemon and
suchlike are just frontends for that adding interactive password queries
and things like that. And yeah, ssh/gpg should just use the keyring too,
and nothing else. But of course this is not going to be easy, as the
kernel keyring is a Linuxism, and ssh+gpg tend to be conservative with
non-portable interfaces...

Lennart

-- 
Lennart Poettering, Red Hat