On Tue, May 09, 2017 at 01:00:00PM +0200, Bert Huijben wrote: > > -----Original Message----- > > From: Stefan Sperling [mailto:s...@elego.de] > > Sent: dinsdag 9 mei 2017 11:26 > > To: Bert Huijben <b...@qqmail.nl> > > Cc: dev@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
