Bug 446953 - seahorse-agent + gpg-agent/kde-settings = 1 GPG agent too many
seahorse-agent + gpg-agent/kde-settings = 1 GPG agent too many
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: seahorse (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Tomáš Bžatek
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-16 14:46 EDT by Carl Roth
Modified: 2015-03-03 17:32 EST (History)
9 users (show)

See Also:
Fixed In Version: Fedora 10
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-06 13:45:02 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Carl Roth 2008-05-16 14:46:45 EDT
Description of problem:

Seahorse agent (yet another keyring replace for gpg) doesn't play well with
kde-settings (specifically, /etc/kde/env/gpg-agent-startup.sh).  If
seahorse-agent is installed and running, and it's providing gpg-agent
functionality via GPG_AGENT_INFO, the gpg-agent-startup-sh script will wrongly
start an extra gpg-agent instance.

The fault lies in the process-id check in gpg-agent-startup.sh.  If
seahorse-agent is being used, the GPG_AGENT_PID points to 'seahorse-agent', not
'gpg-agent'.

Version-Release number of selected component (if applicable):

kde-settings-4.0-22.fc9.1.noarch
seahorse-2.22.1-1.fc9.x86_64

How reproducible:

Always


Steps to Reproduce:
1. Install seahorse-agent
2. Log into a KDE desktop session
3. Note that both gpg-agent and seahorse-agent are running.
  
Actual results:

Expected results:

kde-settings should properly identify that seahorse-agent is already running and
it should not start gpg-agent.

Additional info:
Comment 1 Rex Dieter 2008-05-16 15:08:13 EDT
Ah, 
if [ ! -f "x$GPG_PID_NAME" = "xgpg-agent" ]; then

I suppose we could just take that extra check out.
Comment 2 Rex Dieter 2008-05-16 15:09:11 EDT
Begs a question, does seahorse-agent have similar safe-guards in place so
gpg-agent doesn't get stomped, or is seahorse always preferable, if available?
Comment 3 Kevin Kofler 2008-05-16 15:10:11 EDT
The question it leads me to is: why does seahorse ship its own custom gpg-agent 
in the first place?
Comment 4 Rex Dieter 2008-05-16 15:18:04 EDT
Matthias, seth tells me you've done a lot with seahorse recently, what's your
opinion on how best to handle these multiple agents?
Comment 5 Rex Dieter 2008-05-16 15:20:51 EDT
see also related bug #247616 "gnupg2: gpg-agent autostart, ssh support (RFE)"
(cc'ing nalin)
Comment 6 Kevin Kofler 2008-05-16 15:23:40 EDT
This is why seahorse-agent has been added to seahorse:
http://bugzilla.gnome.org/show_bug.cgi?id=154201

IMHO this is a GNOME-specific service and should only be started in GNOME. 
Other desktops should just use the vanilla gpg-agent. Reassigning to seahorse.
Comment 7 Kevin Kofler 2008-05-16 15:25:38 EDT
IMHO, if the seahorse maintainers refuse to conditionalize this, we should add 
a killall seahorse-agent to /etc/kde/env/gpg-agent-startup.sh.
Comment 8 Kevin Kofler 2008-05-16 15:28:20 EDT
Well, a killall is actually a bit brutal. I guess this is better:
   if [ "x${GPG_PID_NAME}" = "xseahorse-agent" ]; then
     kill $GPG_AGENT_PID
   fi
Comment 9 Carl Roth 2008-05-16 15:36:32 EDT
Note that

1. Gnome-keyring-daemon is not really a gnome or gtk application.  There's no
reason why it shouldn't integrate with KDE/kwallet (hint, hint).

2. It's not acceptable at this time to blacklist seahorse and seahorse-agent for
KDE.  NetworkManager requires gnome-keyring-daemon to handle WEP and VPN
passwords, and AFAIK seahorse/seahorse-agent is the only utility available that
can manage the passwords for gnome-keyring-daemon.
Comment 10 Rex Dieter 2008-05-16 15:40:04 EDT
Kevin, I'd like to think there's some middle ground here so that everything (and
everyone) can work together to find a better solution to this, and hopefully
address the bigger issue around the proliferation of overlapping and conflicting
agents.

Roth, afaik gnome-keyring-daemon works just fine without seahorse-agent it's
just nicer *with* it, afaik.
Comment 11 Kevin Kofler 2008-05-16 15:44:26 EDT
It's obvious what the issue is there, GPG comes with an agent, but the GNOME 
folks decide it is not good enough for them and reinvent the wheel, throwing 
GNOME dependencies into a core system component which should not have a GUI at 
all.
Comment 12 Seth Vidal 2008-05-16 15:47:41 EDT
okay, I don't know what the issue here is with 'gnome folks' or not.

seahorse starts up b/c you can run things like NM and evolution, etc all inside
any desktop. And those tools work much better if the agent is the seahorse agent
b/c it is prettier and nicer (among other things)
Comment 13 Kevin Kofler 2008-05-16 15:48:35 EDT
> Roth, afaik gnome-keyring-daemon works just fine without seahorse-agent

Right, gnome-keyring-daemon has no dependency on seahorse, there's no seahorse 
on the KDE Live spin and I'm not aware of any problems with that.
Comment 14 Kevin Kofler 2008-05-16 15:57:32 EDT
> seahorse starts up b/c you can run things like NM and evolution, etc all
> inside any desktop. And those tools work much better if the agent is the
> seahorse agent b/c it is prettier and nicer (among other things)

But if KDE decides to make its own graphical agent using KDE libs, and that 
also wants to start up under any desktop, what will you do then?

I don't think we want this GNOME-dependent tool autostarted in KDE. We want to 
get rid of GNOME-based background stuff started by default (replace 
NetworkManager-gnome with KDE 4.1's NetworkManager support in F10, replace 
gnome-packagekit with KPackageKit as soon as it's ready, maybe F10 or F11), not 
get more of it forced on us. Now you'll argue that we could just not install 
seahorse (and on the KDE Live spin, that's what we do), but the problem here is 
that the agent is in the same package as the libraries and thus will be dragged 
in as a dependency of some applications. The most obvious of the reasons: 
getting all the GNOME libraries loaded into memory by something always running 
such as those applets is bad for memory consumption.
Comment 15 Kevin Kofler 2008-05-16 16:01:28 EDT
One possible solution: split the package into a seahorse-libs package with the 
libs needed to get apps running and another package (main seahorse package?) 
with the seahorse-agent. If you use this setup:
* seahorse contains seahorse-agent and the xinit script
* seahorse-libs contains everything else
* seahorse Requires: seahorse-libs
* seahorse-libs DOES NOT REQUIRE seahorse
then this should be fairly safe to push as an F9 update too. Any comments?
Comment 16 Kevin Kofler 2008-05-16 16:03:13 EDT
That said, it still wouldn't solve the conflicting agents when seahorse is 
installed, just make it easier to opt out of seahorse-agent.
Comment 17 Kevin Kofler 2008-05-16 16:08:55 EDT
Oops, forget what I said about dependencies and a -libs package, seahorse isn't 
being dragged in as a dep anyway. So there's actually an easy workaround:
rpm -e seahorse

But as I said in comment #16, we need the case fixed where it _is_ installed, 
e.g. on a multi-user machine where both KDE and GNOME are used (by different 
users).
Comment 18 Kevin Kofler 2008-05-16 16:34:34 EDT
Sorry for the comment spam, but I have a question: does gnome-keyring-daemon 
really interact with the seahorse AGENT? Or only with some other parts of 
seahorse, e.g. the seahorse preferences:
http://sadamclemson.blogspot.com/2007/06/seahorse-gnome-keyring-integration.html

In other words, would not starting seahorse-agent in KDE (or killing it as per 
comment #8, but I'd prefer it not to get started in the first place for obvious 
performance reasons) really change anything for gnome-keyring-daemon?
Comment 19 Matthias Clasen 2008-05-16 16:56:20 EDT
> if KDE decides to make its own graphical agent using KDE libs,

...of course, KDE would not do this, since we are talking about

>[...] a core system component which should not have a GUI at all

Mocking aside, seahorse-agent is started from xinitrc.d because it needs to
inject variables into the session environment. The new gnome-session in gnome
2.24 may allow us to run seahorse-agent in the session, and inject the
environment variables into the session via org.gnome.SessionManager.Setenv.

Until then, we can probably add some conditional start mechanism to 
/etc/X11/xinitrc.d/seahorse-agent.sh, if you can come up with some non-gross
mechanism.
Comment 20 Kevin Kofler 2008-05-16 17:37:16 EDT
> Mocking aside, seahorse-agent is started from xinitrc.d because it needs to
> inject variables into the session environment.

I guess you need something like /etc/kde/env. ;-) But more seriously:

> Until then, we can probably add some conditional start mechanism to 
> /etc/X11/xinitrc.d/seahorse-agent.sh, if you can come up with some non-gross
> mechanism.

Thanks, that sounds reasonable, now the question is how. Is there any way to 
figure out in xinitrc.d what kind of session is about to be started?
Comment 21 Kevin Kofler 2008-05-16 17:45:49 EDT
Hmmm, Xsession first runs xinitrc-common (which runs all the xinitrc.d scripts) 
and only then decides what desktop to run, so I guess we need some changes to 
xorg-x11-xinit to fix this cleanly. :-(
Comment 22 Kevin Kofler 2008-05-16 17:52:39 EDT
My suggestion:

* let's work around this in kde-settings one way or the other for now (-> 
reassigning)

* longer-term, this:
> The new gnome-session in gnome
> 2.24 may allow us to run seahorse-agent in the session, and inject the
> environment variables into the session via org.gnome.SessionManager.Setenv.
sounds like the way to go.
Comment 23 Steven M. Parrish 2008-06-21 14:26:29 EDT
Ping.... Just doing a 30day check.  Any resolution to this issue or is it
pending post 4.1
Comment 24 Steven M. Parrish 2008-07-28 16:26:13 EDT
Ping  any movement on this?  Want to leave it open or close it Rex?
Comment 25 Rex Dieter 2008-07-28 16:36:19 EDT
still an outstanding issue, please keep this open.
Comment 26 Steven M. Parrish 2008-09-25 19:42:23 EDT
Ping
Comment 27 Steven M. Parrish 2009-02-06 11:57:08 EST
Probably still an outstanding issue, correct?
Comment 28 Rex Dieter 2009-02-06 12:06:29 EST
no news is bad news, I'm afraid.  not enough round-tuits, retargetting rawhide.
Comment 29 Kevin Kofler 2009-02-06 12:09:28 EST
This really needs to be fixed in seahorse. gnome-session now supports injecting environment variables, so it should be possible to start seahorse in something GNOME-specific now instead of forcing it on everybody.
Comment 30 Matthias Clasen 2009-02-06 13:39:32 EST
Are we beating a dead horse here ? 
seahorse hasn't been shipping an xinitrc.d file for quite a while now...
Comment 31 Kevin Kofler 2009-02-06 13:45:02 EST
Indeed, this appears to be fixed in F10. Looks like we're beating a dead seahorse. ;-)

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