Re: svn commit: r1794433 - /subversion/branches/1.9.x/STATUS

On Tue, May 09, 2017 at 01:00:00PM +0200, Bert Huijben wrote:
>
>
> > -----Original Message-----
> > From: Stefan Sperling [mailto:stsp_at_elego.de]
> > Sent: dinsdag 9 mei 2017 11:26
> > To: Bert Huijben <bert_at_qqmail.nl>
> > Cc: dev_at_subversion.apache.org
> > Subject: Re: svn commit: r1794433 - /subversion/branches/1.9.x/STATUS
> >
> > On Tue, May 09, 2017 at 09:13:57AM +0200, Bert Huijben wrote:
> > > I haven’t investigated this any further, but do we now try to start the
> > > gpg-agent on every invocation of a command just to poll if we perhaps
> > have a
> > > GPG agent running, and might want to use that authentication option?
> >
> > No. gpgconf is not gpg-agent.
> > gpgconf is a tool for querying configuration parameters of gnupg.
> > https://www.gnupg.org/documentation/manuals/gnupg/gpgconf.html#gpg
> > conf
> >
> > No agent is started when I run this:
> > $ gpgconf --list-dir agent-socket
> > /home/stsp/.gnupg/S.gpg-agent
>
> But 'gpgpconf' is started.
>
> The problem is that we just start external code... Which executable doesn't
> matter that much.

> This is no longer some small trivial change... It changes outside
> dependencies and security boundaries.

OK, I see your point.

It seems the original motivation for this change was that gpg-agent
has now moved its socket to /run/user/UID/gnupg in the Linux world.
We could add custom code which looks for a socket there instead of
calling out to a binary. The only downside is that if Linux again changes
its current way of working, we'll have to keep piling on hacks to keep
things working rather than relying on gpgconf as an abstraction.
But that's probably just the way it is with Linux.
Received on 2017-05-09 13:30:55 CEST