Discussion:
svn not using gpg-agent
Michael Thayer
2016-09-28 16:18:04 UTC
Permalink
(Not subscribed, please CC me on answers. Thanks!)

Hello,

I suspect this is a user problem somewhere, but since I upgraded to
Ubuntu 16.10 (Subversion 1.9.4 versus 1.9.3 in 16.04) svn has stopped
using GPG-Agent and started using GNOME Keyring to store my password.
As a test, I deleted all GNOME Keyring passwords, deleted the local
.subversion folder and recreated it with "svn --version", changed the
password-stores line to "password-stores = gpg-agent" and updated. The
password was saved to the GNOME Keyring again. For a little bit more
security I would really prefer GPG-Agent though. (For the record, the
GNOME Keyring FAQ seems to disagree with your FAQ about other
applications accessing stored passwords.<1><2> But it seems about the
best option just now. It would be great if svn could fork off a daemon
process itself which would hang around for a while and do the actual
work, but I digress.)

Any ideas welcome.

Thanks!

Michael

$ svn --version
svn, version 1.9.4 (r1740329)
[...]
The following authentication credential caches are available:

* Plaintext cache in /home/michael/.subversion
* Gnome Keyring
* GPG-Agent
* KWallet (KDE)

<1> https://subversion.apache.org/docs/release-notes/1.8.html#gpg-agent
<2> https://wiki.gnome.org/Projects/GnomeKeyring/SecurityFAQ "Can one
application see another application's secrets?"
--
Michael Thayer | VirtualBox engineer
ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | D-71384 Weinstadt

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstraße 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister
der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
James McCoy
2016-10-27 03:24:30 UTC
Permalink
Post by Michael Thayer
Hello,
Hi!
Post by Michael Thayer
I suspect this is a user problem somewhere, but since I upgraded to Ubuntu
16.10 (Subversion 1.9.4 versus 1.9.3 in 16.04) svn has stopped using
GPG-Agent and started using GNOME Keyring to store my password.
In Ubuntu 16.10, gnupg changed from the 1.4.x series to the 2.x series.
With that, gpg-agent now will start on-demand when needed, whereas with
the old gnupg it needed to be manually started.

Svn currently detects whether it can use gpg-agent by looking for the
UNIX socket that's used to communicate with the agent. It finds this
either through the GPG_AGENT_INFO environment variable or looking for
~/.gnupg/S.gpg-agent socket. It sounds like neither of those exist in
your setup.

$GPG_AGENT_INFO should be defined for your X session by
/etc/X11/Xsession.d/90gpg-agent, and there are also some hints in the
file about how to ensure the agent gets started.

While the above isn't a solution, hopefully it's enough information to
figure out where the disconnect is.

Cheers,
--
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Michael Thayer
2018-09-05 10:49:31 UTC
Permalink
Hello James,

Two years later...
Post by James McCoy
Post by Michael Thayer
I suspect this is a user problem somewhere, but since I upgraded to Ubuntu
16.10 (Subversion 1.9.4 versus 1.9.3 in 16.04) svn has stopped using
GPG-Agent and started using GNOME Keyring to store my password.
In Ubuntu 16.10, gnupg changed from the 1.4.x series to the 2.x series.
With that, gpg-agent now will start on-demand when needed, whereas with
the old gnupg it needed to be manually started.
Svn currently detects whether it can use gpg-agent by looking for the
UNIX socket that's used to communicate with the agent. It finds this
either through the GPG_AGENT_INFO environment variable or looking for
~/.gnupg/S.gpg-agent socket. It sounds like neither of those exist in
your setup.
$GPG_AGENT_INFO should be defined for your X session by
/etc/X11/Xsession.d/90gpg-agent, and there are also some hints in the
file about how to ensure the agent gets started.
While the above isn't a solution, hopefully it's enough information to
figure out where the disconnect is.
Thank you! It seems like that script isn't getting executed, possibly
due to the Wayland session. If I source it manually things work again.

Regards
Michael
--
Michael Thayer | VirtualBox engineer
ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | D-71384 Weinstadt

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstraße 25, D-80992 MÃŒnchen
Registergericht: Amtsgericht MÃŒnchen, HRA 95603

KomplementÀrin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
GeschÀftsfÌhrer: Alexander van der Ven, Jan Schultheiss, Val Maher
Loading...