Subversion HTTPS password caching using GPG-Agent?

Question

I am using the Subversion client (version 1.9.5 r1770682, installed from the default package repository) on a Debian Stretch machine, to which I only have SSH access. I am connecting to a Subversion repository via HTTPS and would like to avoid having to re-type my password every time I perform an svn up or svn ci command. I would also like to avoid having to store the password on disk as plaintext.

The SVN Book suggests that I should be able to use GPG-Agent as a means of caching my password. Although svn --version reports that the GPG-Agent authentication credential cache should be available, I am having some trouble getting it to work.

With regard to GPG, I have created a GPG key pair, have added export GPG_TTY=$(tty) to my .profile file, and have verified that GPG works by encrypting and decrypting a piece of text.

With regard to Subversion, in my .subversion/config file, I have set the following:

$ grep '^[^#]' < .subversion/config
[auth]
password-stores = gpg-agent
[helpers]
[tunnels]
[miscellany]
[auto-props]
[working-copy]

In my .subversion/servers file, I have set the following:

$ grep '^[^#]' < .subversion/servers
[groups]
[global]
store-passwords = yes
store-plaintext-passwords = no

When I perform an svn command, however, no passwords are cached. Does anyone have any suggestions as to what I may be doing wrong? Has anyone used GPG-Agent successfully for caching HTTPS passwords? (Perhaps this credential cache is only intended for SVN+SSH connections?)

Any help would be greatly appreciated.

Answer 1

I finally found a solution to my problem by looking into it once more, starting from the suggestion of Roman above. The comments of the find_gpg_agent_socket function in the Subversion client's GPG-Agent authentication source code indeed explain:

$GPG_AGENT_INFO takes precedence, if set, otherwise $GNUPGHOME will be used.

(...)

For reference GPG_AGENT_INFO consists of 3 : separated fields. The path to the socket, the pid of the gpg-agent process and finally the version of the protocol the agent talks.

The path to the GPG-Agent socket can easily be found by calling gpgconf --list-dirs agent-socket on the command line. The other two segments of the $GPG_AGENT_INFO variable are not used by the Subversion client, and should thus not necessarily be set.

I have therefore added the following code at the end of my .profile file:

export GPG_TTY=$(tty)
export GPG_AGENT_INFO=`gpgconf --list-dirs agent-socket | tr -d '\n' && echo -n ::`

This sets the $GPG_TTY variable to the current terminal, and the $GPG_AGENT_INFO variable to the GPG-Agent socket, followed by two colon characters (i.e., the format expected by the Subversion source code).

Subversion seems to cache the repositories' authentication settings in ~/.subversion/auth, so I found it necessary to clear that directory before GPG-Agent would be used correctly:

rm -rf ~/.subversion/auth

After starting a new session, you should be able to verify that the $GPG_AGENT_INFO variable is set correctly: echo $GPG_AGENT_INFO should output something like /run/user/1000/gnupg/S.gpg-agent:: (where 1000 is the uid of the current user).

When performing a Subversion command, for example svn up, your password will be prompted the first time:

Updating '.':
Enter your Subversion password for <https://example.com:443> Subversion Repository
Password for 'username': :
At revision 123.

When performing a second Subversion command for the same repository for some time afterwards, Subversion should use the password cached by GPG-Agent:

Updating '.':
At revision 123.

Edit: I have the impression that, when using a repository for the first time (i.e., when it is not yet present in Subversion's cache), the password is only correctly saved by GPG-Agent after entering it twice.

Answer 2

This thread seems to give a hint: https://groups.google.com/forum/#!topic/subversion_users/WS8Cr7mAovQ

I'm running Xfce on Ubuntu, and I had the same problem. Apparently, the reason is that the $GPG_AGENT_INFO environment variable is not set. Manually running the /etc/X11/Xsession.d/90gpg-agent script (which sets this variable) did help me.