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#gpgconf
No agent is started when I run this:
$ gpgconf --list-dir agent-socket
/home/stsp/.gnupg/S.gpg-agent
In the source code [1] it looks like what is printed is the path
to the configuration directory (/run/user/UID/gnupg on Linux) and
the static string "/S.gpg-agent" (a gnupg compile-time default).
[1] https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=tools/gpgconf.c;h=2236555671b2f33b36e6985ded93ebfcafef344d;hb=refs/heads/master
So gpgconf does the same as this part of our code except it does not
need the GNUPGHOME environment variable:
else if ((gnupghome = getenv("GNUPGHOME")) != NULL)
{
const char *homedir = svn_dirent_canonicalize(gnupghome, pool);
socket_name = svn_dirent_join(homedir, "S.gpg-agent", pool);
}
> I don’t think we want to do that as a simple replacement of a cheap check of
> an environment variable as we did before. There is also a long list of
> applications where just executing a program by name (without path or
> anything) is called a security problem.
Well, it seems that GnuPG 2.x has changed the way this works and we
don't have much choice if we want to keep supporting gpg-agent.
I am fine with restricting the PATH if that's a concern. Not sure what
this would look like on Windows but we could probably restrict it to
something like "/usr/bin:/usr/local/bin" on Unix-like systems without
much risk of breaking this functionality.
Received on 2017-05-09 11:26:59 CEST