> -----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.
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
The code forks the process, which may have severe consequences in certain
environments involving threads (running inside Eclipse?)
This is no longer some small trivial change... It changes outside dependencies
and security boundaries.
Bert
