gpg-agent environment variables not correctly exported

Bug #1257706 reported by Guillaume Martres
36
This bug affects 6 people
Affects Status Importance Assigned to Milestone
gnupg2 (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Since Ubuntu 13.10, there is an Upstart script /usr/share/upstart/sessions/gpg-agent.conf which launches the gpg-agent daemon and then export the GPG_AGENT_INFO environment variable:
   initctl set-env --global GPG_AGENT_INFO=$GPG_AGENT_INFO
This is enough to prevent the /etc/X11/Xsession.d/90gpg-agent script from launching gpg-agent itself, but it's not enough to actually use gpg-agent, you also need to export SSH_AUTH_SOCK and SSH_AGENT_PID.

Tags: saucy
Revision history for this message
Michael Bienia (geser) wrote :

It depends on what you intend to use gpg-agent for. For caching of your passphrase of your gpg private key, I assume you don't need the SSH variables exported. But if you want gpg-agent to use as a ssh-agent too, you need to pass --enable-ssh-support to gpg-agent and export SSH_AUTH_SOCK (the man page only mentions SSH_AUTH_SOCK in the examples).

I use gpg-agent as a ssh-agent too, so I can use my OpenPGP card for SSH authentication. I've attached my ~/.init/gpg-agent.conf (used by upstart user sessions) which starts gpg-agent with --enable-ssh-support and exports SSH_AUTH_SOCK. Put it in your ~/.init/ and upstart will use it instead the one from the package.

I doubt this can be included in the package itself (perhaps as an example for those users who need it) as gpg-agent will then compete with ssh-agent (from the openssh-client package) who sets the SSH_AUTH_SOCK variable and might upset users of ssh-agent. gnome-keyring can also act as a ssh-agent so there are at least three competioners for that variable.

Revision history for this message
Alex Mauer (hawke) wrote :

I really like this, but I think it could be improved:
You don’t really need to pass --enable-ssh-support.

Instead, you can place the option in the gpg-agent.conf file (~/.gnupg/gpg-agent.conf)

This way there is no need to worry about competing with ssh-agent.

So the only thing to really worry about then, is exporting the appropriate environment variables, and it should be palatable to ssh-agent users.

I think this change could be included in the official package too, with no problem.

There is some inconsistency among the various *-agents though: To disable the ssh-agent you edit /etc/X11/Xsession.options; to enable the gpg-agent you edit ~/.gnupg/gpg.conf; to enable ssh support in gpg you edit ~/.gnupg/gpg-agent.conf; and to disable ssh support in gnome-keyring (the default) you have to hack around in /etc/xdg/autostart/gnome-keyring-*.desktop. It’s a real mess.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gnupg2 (Ubuntu):
status: New → Confirmed
Revision history for this message
Alex Mauer (hawke) wrote :

It would also be best if the gpg-agent was started before dbus, so that gvfsd (which is started by dbus) can use the gpg agent information. (e.g. using the agent to access ssh URLs)

Revision history for this message
fl0 (fl0) wrote :

Would also be nice, if the agent information could be used by nautilus. I guess this is currently not working because the environment variables cannot be used inside the GUI?

Revision history for this message
Janis Danisevskis (werwurm) wrote :

I am another user of OpenPGP-Card ssh authentication.

I have my init/gpg-agent.conf attached. It checks ~/.gnupg/gpg-agend.conf for the enable-ssh-support option and exports the SSH_ variables conditionally.

I agree with Alex Maurer that the various *-agents start-scritps are quite messy. But then they stem from various projects, so where is the right place to start this discussion?

Revision history for this message
neagix (neagix) wrote :

I have recently updated my blog post/rant about this whole class of issues.

For users/developers that want a recap and a working approach:
http://neagix.blogspot.co.uk/2014/09/setup-gpg-smartcard-reader-in-ubuntu-14.html

Feel free to merge the proposed xsession script, if you evaluate it to be of enough quality.

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

gnupg2 is not in main, ubuntu uses gnupg1 by default.
in vivid, and being fixed in sru's for trusty and utopic, upstart is managing user session and launching gnupg-agent (either gnupg1 or gnome-keyring), ditto ssh-agent (either gnupg1 or gnome-keyring).

To integrate this correctly, support should be added to ssh-agent/gnome-keyring-ssh & gpg-agent/gnome-keyring-gpg to support third alternative, that is gnupg2's gpg-agent and gnupg2's ssh-agent. Patches against that are welcome.

With respect to gpg smartcard, on my machine i've copied gnupg-agent.conf job into ~/.config/upstart/ an tweaked it to export ssh-agent vairable, and also did "echo manual > ~/.config/upstart/ssh-agent.override" and thus i'm using gnupg gpg-agent for both ssh & gpg authentication.

Revision history for this message
neagix (neagix) wrote :

I see, it's in extra.

Correction: the proposed xsession script is unnecessary, as the stock 90gpg-agent works fine when ~/.gnupg/gpg-agent.conf is correctly populated, sorry for the blunder.

@xnox so you managed to do it via upstart instead of Xsession? Interesting.

Mathew Hodson (mhodson)
tags: added: saucy
Revision history for this message
Mark Adams (kramsmada) wrote :

I've had a merge proposal in with a patch to fix this since January. If someone could review and merge, I'd appreciate it:

https://code.launchpad.net/~kramsmada/ubuntu/vivid/gnupg2/1407513-gpg-agent-set-ssh-env-vars/+merge/245538

Revision history for this message
Mark Adams (kramsmada) wrote :

Please let me know if I didn't do this merge proposal correctly, this is my first one.

https://code.launchpad.net/~kramsmada/ubuntu/vivid/gnupg2/1407513-gpg-agent-set-ssh-env-vars/+merge/245538

Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

I think the merge request looks good. Once the dev release opens, it can be uploaded.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.