[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Mark Phippard <markphip_at_gmail.com>
Date: Tue, 9 May 2017 09:36:18 -0400

On Tue, May 9, 2017 at 8:02 AM, James McCoy <jamessan_at_jamessan.com> wrote:

> > 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.
I would expect a feature like this to at least require some kind of opt-in
mechanism. In this case, it should require some setting in config that is
not on by default. I get that we just want to make things work for users
as easily as possible but just blindly launching an executable does not
seem like the correct approach to me.

Mark Phippard
Received on 2017-05-09 15:36:25 CEST

This is an archived mail posted to the Subversion Dev mailing list.