Bug 446953

Ah, 
if [ ! -f "x$GPG_PID_NAME" = "xgpg-agent" ]; then

I suppose we could just take that extra check out.

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?

The question it leads me to is: why does seahorse ship its own custom gpg-agent 
in the first place?

Matthias, seth tells me you've done a lot with seahorse recently, what's your
opinion on how best to handle these multiple agents?

see also related bug #247616 "gnupg2: gpg-agent autostart, ssh support (RFE)"
(cc'ing nalin)

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.

IMHO, if the seahorse maintainers refuse to conditionalize this, we should add 
a killall seahorse-agent to /etc/kde/env/gpg-agent-startup.sh.

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

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.

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.

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.

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)

> 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.

> 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.

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?

That said, it still wouldn't solve the conflicting agents when seahorse is 
installed, just make it easier to opt out of seahorse-agent.

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).

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?

> 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.

> 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?

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. :-(

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.

Ping.... Just doing a 30day check.  Any resolution to this issue or is it
pending post 4.1

Ping  any movement on this?  Want to leave it open or close it Rex?

still an outstanding issue, please keep this open.

Ping

Probably still an outstanding issue, correct?

no news is bad news, I'm afraid.  not enough round-tuits, retargetting rawhide.

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.

Are we beating a dead horse here ? 
seahorse hasn't been shipping an xinitrc.d file for quite a while now...

Indeed, this appears to be fixed in F10. Looks like we're beating a dead seahorse. ;-)