Moving the agent's socket to /var/run ?
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Fri Feb 26 04:23:48 CET 2016
On Wed 2016-02-24 16:55:24 +0100, Werner Koch <wk at gnupg.org> wrote:
> On Wed, 24 Feb 2016 03:13, dkg at fifthhorseman.net said:
>> Debian definitely has them. they're a good idea, and i'd be happy to
>> use them.
> Great. Do you expect a name conflict due to our socket names:
I don't forsee a name conflict with those names, but currently
everything else on my own (admittedly non-standard system) uses a
subdirectory (e.g. /run/user/$(id -u)/dconf/ and /run/user/$(id
>> The right place to try if XDG_RUNTIME_DIR is not available is
> We would figure that out at runtime so that it will also work work if
> /var/run is not a symlink to run.
Sounds fine. If both /run and /var/run exist, and one is not a symlink
or a bind-mount of the other, and XDG_RUNTIME_DIR is not set, i'd prefer
to default to /run/user over /var/run/user, but that is such a corner
case that i'm not particularly concerned about it.
>> Is this going to be the new "standard socket" location? If so, how
> For Unix it should be the default for 2.1 unless a configure option is
> used to revert to the old behaviour. For Windows there is no need to
> change it.
sounds great to me.
>> should we help people transition who have already been running with the
>> old "standard socket" location?
> All proper applications should use gpgconf to find the agents sockets,
> Except for redirect sockets the only problem I see is that an already
> running agent would not be used by 2.1 and a running scdaemon might have
> locked the smartcard.
right, in the worst case for this newer-gpg and older-agent, gpg will
just fire up a new instance of the agent and forget about/ignore the old
For smartcard users, they would need to manually kill off the old agent
What about for older-gpg and newer-agent combinations, though? if an
older gpg 2.1 tries to auto-launch a newer agent, and the agent listens
on a different socket than gpg was expecting, they might never
> What to do with gnupg 2.0 ? Backport the changes or keep using the old
> system? I'd say to keep the old system.
by "the old system" you mean looking at $GPG_AGENT_INFO? or looking
> For 1.4, which uses gpg-agent mainly as a passphrase cache, I would
> suggest to backport the change in a way that /var/run is tried before
> ~/.gnupg - it is only about the client code.
that sounds reasonable to me.
More information about the Gnupg-devel