Bug 247616 - gnupg2: gpg-agent autostart, ssh support (RFE)
gnupg2: gpg-agent autostart, ssh support (RFE)
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: gnupg2 (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-10 09:18 EDT by Giuseppe Paterno
Modified: 2016-09-02 08:10 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-09-02 08:10:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
gpg-agent autostart for X (620 bytes, text/plain)
2007-07-10 09:18 EDT, Giuseppe Paterno
no flags Details
Scripts and configuration for agent (622 bytes, application/x-bzip2)
2008-11-24 08:03 EST, Christian Tosta
no flags Details
Spec file for gpg-agent-startup packages (3.30 KB, application/octet-stream)
2008-11-24 08:05 EST, Christian Tosta
no flags Details

  None (edit)
Description Giuseppe Paterno 2007-07-10 09:18:29 EDT
gpg-agent is not setted to start with gnome/kde/X session.
Wrote a script to autostart gpg-agent with ssh support for the logging user.
The included gpg-agent.sh should be placed in:
/etc/X11/xinit/xinitrc.d

Maybe fedora only?
This script could be made better to maybe include some boolean (if to start or
not) and/or to enable ssh.
Comment 1 Giuseppe Paterno 2007-07-10 09:18:29 EDT
Created attachment 158854 [details]
gpg-agent autostart for X
Comment 2 Rex Dieter 2007-07-10 09:30:40 EDT
fyi,
/etc/kde/env/gpg-agent-startup.sh
/etc/kde/shutdown/gpg-agent-shutdown.sh 
are already included in the packaging, but these directories are kde-only.

I considered doing something like your xinitrd.d approach in the past, but
couldn't find any way to shutdown/kill gpg-agent at the end of a session.

Comment 3 Rex Dieter 2007-07-10 09:32:35 EDT
and existing gpg-agent-startup.sh doesn't include --enable-ssh-support
Looks like something good to add.
Comment 4 Giuseppe Paterno 2007-07-11 03:22:27 EDT
Looks like KDE handles session shutdown.
If you are going to enable the ssh support, I believe it should be better to
write the complete environment using --write-env-file so that you have also the
env you can import into bashrc.

Anyway the env GPG_AGENT_INFO contains the PID of the process, eg:
echo $GPG_AGENT_INFO | cut -d: -f2
you have the pid.

It's a matter of finding the right hook in gnome to kill the process in
shutdown. My workaround in the script is not to start again the gpg-agent in a
new session.

Maybe the script could be rewritten in such a way the full env could be importe
if the gpg-agent is already running for the user.

If you're interested in, I'll investigate further.
Comment 5 Giuseppe Paterno 2007-07-11 04:08:30 EDT
Looks like that in GDM:
/etc/gdm/PreSession/Default -> do the pre-session stuff
/etc/gdm/PostSession/Default -> do the shutdown phase

We can either:
insert a run of scripts in dir such as /etc/gdm/PreSession.d/ or insert a
gpg-agent directly into Default.

My concerns are about seahorse-agent that should do the same role of gpg-agent but:
1) does not support ssh 
2) does not handle correctly OpenPGP smartcards (as in my case)

Anyway it should be better interact with the GDM fellows to insert an official
PreSession startup
Comment 6 Rex Dieter 2007-07-17 10:51:10 EDT
sounds promising, I'll see if we can get some feedback on fedora-devel...
Comment 7 Bug Zapper 2008-05-14 09:29:46 EDT
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 8 Rex Dieter 2008-05-14 09:48:04 EDT
I'd like to keep this RFE around awhile longer...
Comment 9 Nalin Dahyabhai 2008-05-14 12:48:04 EDT
We've got several things that want to replace ssh-agent (IIRC both seahorse and
gnome-keyring also want the job) -- we can't autostart them all.  I think we
need a bigger plan here.
Comment 10 Rex Dieter 2008-05-14 12:57:07 EDT
nod, I asked on fedora-devel awhile back, to deafening silence.  Not sure why
everyone wants to re-invent the wheel here (since afaik, seahorse replaces
gpg-agent as well). 
Comment 11 Nalin Dahyabhai 2008-05-16 13:12:40 EDT
Sorry I missed it.  I'm not sure how to proceed from here, then.
Comment 12 Rex Dieter 2008-05-16 13:21:36 EDT
Try, try again. :)  When/if I find a few spare cycles, I'll try to whip
something up (but if anyone else has notions, by all means, don't block on me).
Comment 13 hawke 2008-07-10 16:28:38 EDT
IMO it would be a good start to at least make it so that the user can change
which agent is started instead of forcing ssh-agent in the
/etc/X11/xinit/Xsession script, as is currently done.
Comment 14 hawke 2008-07-10 17:06:44 EDT
Also, regarding "couldn't find any way to shutdown/kill gpg-agent at the end of
a session." -- it seems (works for me) that gpg-agent when run with --daemon,
will accept a command to run, just as ssh-agent does (dying when the command does)

So simply substituting "/usr/bin/gpg-agent --enable-ssh-support --daemon" for
"/usr/bin/ssh-agent" in xinitrc-common does the job just fine. (as a replacement
for ssh-agent).  To run it in addition to the openssh ssh-agent, it might be
possible to chain them together ("/usr/bin/gpg-agent --daemon /usr/bin/ssh-agent".

It's also necessary to turn off gnome-keyring's ssh-agent support as it will
overwrite gpg-agent's setting of SSH_AUTH_SOCK, but that seems fairly trivial.
Comment 15 Carl Roth 2008-07-10 17:33:54 EDT
... unless you would prefer that gnome-keyring handle your SSH keys.  If you're
running pam_gnome_keyring, then you only have to unlock your SSH key once in the
life of your login keyring.

On my system, I've hacked xinitrc-common to unset the SSH_AGENT launcher setting
for xinit.  I would prefer that the gpg-agent stand-in (either gpg-agent or
seahorse-agent) or gnome-keyring be used for SSH keys.

The other thing to watch out for is in BUG446781 -- gnome-keyring is an adequate
ssh-agent replacement, but since it doesn't set SSH_AGENT_PID, it gets clobbered
by the SSH_AGENT_PID check in xinitrc-common.  I ended up splicing in a value
for SSH_AGENT_PID in a xinitrc.d scriptlet.
Comment 16 hawke 2008-07-10 18:06:52 EDT
I don't consider gnome-keyring to be an adequate ssh-agent replacement.  Hence
my initial suggestion to "make it so that the user can change which agent is
started".  I've also modified my xinitrc-common so that gpg-agent is used
instead of ssh-agent.

gnome-keyring is useless to me because it doesn't provide access to
authentication keys stored on a smart card (as gpg-agent does) and because it
doesn't provide a method for an app to check that a given password/key is in the
keyring without unlocking the keyring.  But that's another gripe entirely.
Comment 17 Carl Roth 2008-07-10 18:24:10 EDT
Then I think we would both be served better if xinitrc-common didn't clobber
SSH_AGENT.  The agent implementation could then be fully customized in xinitrc.d
scripts.  But this is not a gnupg2 issue, it's an xorg-x11-xinit issue.
Comment 18 Christian Tosta 2008-11-24 08:01:54 EST
This was fixed for Ekaaty Linux (a Fedora based distro) with packages gpg-agent-startup-{kde,gnome}.
Comment 19 Christian Tosta 2008-11-24 08:03:38 EST
Created attachment 324469 [details]
Scripts and configuration for agent
Comment 20 Christian Tosta 2008-11-24 08:05:04 EST
Created attachment 324470 [details]
Spec file for gpg-agent-startup packages
Comment 21 Rex Dieter 2008-11-24 08:55:03 EST
gpg-agent already autostarts in kde in fedora (albeit, not with a separate pkg as described here), and when queried, the gnome-desktop folks weren't keen on enabling that same support for gnome (as a matter of fact, claimed there wasn't a technical solution even to do so, interesting to see an implementation is possible).

Christian, the gpg-agent-startup-kde is good for only up to F-8, for F-9+ Requires: kdebase3 is wrong (should be kdebase-workspace-devel, or just leave it out).  I appreciate what Ekaaty is trying to do here, but they(you?) would be much better served coordinating such changes with upstream here.  I'd love to see more love/interest making this all better, esp with downstream input.

Regardless, these comments are outside the scope of *this* bug, which is about enabling ssh agent support in gpg-agent.  :)

Time to bite-the-bullet here, and actually do some planning/work to get this *-agent mess unified and sorted out.  Perhaps in the F-11 time-frame.  Means, 
1.  See what other distros have done or are planning in this problem-space
2.  ping all interested parties (gpgme, seahorse, gnome-keyring, etc...) for input, requirements
3.  code, feedback
... miracles occur ...
99. profit!
Comment 22 Christian Tosta 2008-11-25 11:30:57 EST
(In reply to comment #21)
> Christian, the gpg-agent-startup-kde is good for only up to F-8, for F-9+
> Requires: kdebase3 is wrong (should be kdebase-workspace-devel, or just leave
> it out).  I appreciate what Ekaaty is trying to do here, but they(you?) would
> be much better served coordinating such changes with upstream here.  I'd love
> to see more love/interest making this all better, esp with downstream input.

Ekaaty 3 is based on Fedora 9, but it comes with KDE (Mod) 3.5.10. That is why the package requires the kdebase3 and not kde-devel-workspace. Otherwise, gpg-agent-startup is good for F-8- as you say.

> Regardless, these comments are outside the scope of *this* bug, which is about
> enabling ssh agent support in gpg-agent.  :)

Hum... I will think about whether there is a way to include ssh-agent in its implementation. Where can I give a feedback.
Comment 23 Rex Dieter 2008-11-25 11:34:15 EST
> Ekaaty 3 is based on Fedora 9, but it comes with KDE (Mod) 3.5.10

Interesting, didn't know that.  thanks.
Comment 24 Patrick C. F. Ernzer 2010-01-23 16:18:27 EST
(In reply to comment #20)
> Created an attachment (id=324470) [details]
> Spec file for gpg-agent-startup packages    

It seems that in F12, gnome, Presession and Postsession have been renamed to mixed caps (/etc/gdm/PostSession and /etc/gdm/PreSession)
Comment 25 Patrick C. F. Ernzer 2010-01-28 04:36:08 EST
just changing the 2 directories in the spec file was not enough, will need SELinux adaptation.
Comment 28 Fedora Admin XMLRPC Client 2013-10-09 10:53:45 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 29 Tomas Mraz 2016-09-02 08:10:38 EDT
This should be at least partially fixed in gnupg 2.1.x

Note You need to log in before you can comment on or make changes to this bug.