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.
