On Tue, May 09, 2017 at 09:36:18AM -0400, Mark Phippard wrote:
> 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.
ACK. I'll commit an earlier version of Lukas' patch, which hard-coded
the paths, to trunk and update the nomination after that.
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Received on 2017-05-10 14:35:09 CEST