Кэширование паролей HTTPS в Subversion с помощью GPG-агента?

Question

Я использую клиент Subversion (версия 1.9.5 r1770682, установленная из репозитория пакетов по умолчанию) на машине Debian Stretch, к которой у меня есть только доступ по SSH. Я подключаюсь к хранилищу Subversion через HTTPS и хотел бы избежать повторного ввода пароля каждый раз, когда я выполняю svn up или же svn ci команда. Я также хотел бы избежать необходимости хранить пароль на диске в виде открытого текста.

Книга SVN предполагает, что я должен иметь возможность использовать GPG-Agent для кэширования своего пароля. Хотя svn --version сообщает, что кэш учетных данных для аутентификации GPG-Agent должен быть доступен, у меня возникли проблемы с его работой.

Что касается GPG, я создал пару ключей GPG, добавил export GPG_TTY=$(tty) к моему .profile файл, и проверили, что GPG работает, зашифровав и расшифровав часть текста.

Что касается Subversion, по моему .subversion/config файл, я установил следующее:

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

В моем .subversion/servers файл, я установил следующее:

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

Когда я выполняю svn Команда, однако, пароли не кешируются. У кого-нибудь есть предложения относительно того, что я могу делать не так? Кто-нибудь успешно использовал GPG-Agent для кеширования паролей HTTPS? (Возможно, этот кэш учетных данных предназначен только для соединений SVN+SSH?)

Любая помощь будет принята с благодарностью.

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

Этот поток, кажется, дает подсказку: https://groups.google.com/forum/

Я запускаю Xfce на Ubuntu, и у меня была та же проблема. Видимо, причина в том, что$GPG_AGENT_INFOпеременная окружения не установлена. Мне помог ручной запуск сценария /etc/X11/Xsession.d/90gpg-agent (который устанавливает эту переменную).