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.
>
> Subversion is a library and we should be very careful about this. I think this code is by default left out on Windows, but there are tons of cert reports where just loading a library dynamically to test something is a security problem, and just running an executable is far worse.
>
> I don't see a problem with enabling this if we know the user uses gpg, but doing this on every auth request just to see if gpg can theoretically be used as backend is too much for me.

Unfortunately, with newer gnupg there isn't always an agent running.
It's started on-demand, if needed. That means we may not have
$GPG_AGENT_INFO to check or an existing socket that we can use.

> The function to test if there is a gpg store becomes several orders of magnitude slower, while we don't even cache the result... because the code used to be blazingly fast

Would it be amenable to cache the value, similarly to what's being done
for kwallet/gnome-keyring? Isn't that cache only live for the duration
of the client process? How typicaly is it to actually need to re-auth
so the cache is re-used?

I saw this as a stop gap measure to help people using newer GnuPG, until
I have time to look at using gpgme instead.

Cheers,

-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB