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

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

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
Received on 2017-05-09 13:00:11 CEST