Moving the agent's socket to /var/run ?

[Daniel Kahn Gillmor]

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:
>
>   S.gpg-agent
>   S.gpg-agent.ssh
>   S.scdaemon
>   S.dirmngr
>   S.uiserver

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
-u)/pulse/).

>> The right place to try if XDG_RUNTIME_DIR is not available is
>> /run/user/<uid>/
>
> 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
one.

For smartcard users, they would need to manually kill off the old agent
once, right?

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
connect...

> 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
somewhere else?

> 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.

     --dkg