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

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2017-05-09 15:36:25 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.