https://bugzilla.novell.com/show_bug.cgi?id=710038 https://bugzilla.novell.com/show_bug.cgi?id=710038#c2 --- Comment #2 from Guido Berhörster 2011-08-09 10:21:06 UTC --- The current situation is a bit complicated, having gnome-keyring automatically unlocked on login involves a startup process in two steps, first it must be started and unlocked via the PAM module on login and after that the desired components (e.g. gpg-/shh-agent functionality) need to be initialized again and certain environment variables need to be set for the session. Details are at http://live.gnome.org/GnomeKeyring/RunningDaemon. The main problem with the current Xfce desktop is that these environment variables are not properly set if GNOME-compatibility mode is disabled. Because the components of gnome-keyring are initialized from desktop files in /etc/xdg/autostart the environment variables printed to stdout are simply lost. When using GNOME, gnome-keyring passes the environment variables via DBus to gnome-session, Xfce however doesn't implement that DBus interface and the only way to get these environment variables is enabling the GNOME-compatibility mode in xfce4-session which will run gnome-keyring --start again, capture its output and set the environment variables accordingly. This has two unwanted side-effects, gnome-keyring --start seems to enable all of gnome-keyring's components making it impossible to selectively disable components by modifying the corresponding autostart files and of course xfce4-session's GNOME-compatibility mode will also start everything in /etc/xdg/autostart which is marked OnlyShowIn=GNOME. A separate but related problem affects the usage of plain GPG/SSH-agents without gnome-keyring. gpg-agent which can also provides ssh-agent functionality is started twice by default, first in /etc/X11/xdm/sys.xsession and later again in /etc/xdg/xfce4/xinitrc and that even if the gpg-agent functionality of gnome-keyring is used. /etc/X11/xdm/sys.xsession will not try to start ssh-agent if gnome-keyring is already running (although a running gnome-keyring does not necessarily imply that ssh-agent functionality will be provided because that could be disabled). /etc/X11/xdm/sys.xsession will however unconditionally start either seahorse-agent if seahorse is installed and the session is GNOME (although it would be perfectly fine to use with Xfce) or fall back to gpg-agent if installed. When gnome-keyring provides gpg-agent functionality this results in a useless seahorse-/gpg-agent process running in the session and is also inconsistent with how ssh-agent is handled. /etc/xdg/xfce4/xinitrc then does not detect an already running gpg-agent and starts yet another instance of gpg-agent with ssh-agent functionality (which may also be potentially useless if the corresponding gnome-keyring functionality is enabled) and thereby breaks the usage of plain ssh-/gpg-agent. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=710038 https://bugzilla.novell.com/show_bug.cgi?id=710038#c4 --- Comment #4 from Guido Berhörster 2011-08-31 22:33:30 UTC --- (In reply to comment #3)

OK, trying to find a different way to make this work.

So if I would start gnome-keyring-daemon from my login script, i.e. .login for C-shell and derivatives, and set

GNOME_KEYRING_CONTROL GNOME_KEYRING_PID

in the environment is this sufficient to get things moving or is the login shell too late?

Yes, that's too late, it will only affect the current shell. This would have to go into the session wrapper, but rather than such a hack the real solution would be to move the gnome-keyring support out of the GNOME compatibility mode of xfce4-session and make it a separate option. That's something I need to bring up with upstream but haven't gotten round to yet. Unfortunately even that would not provide the ability to selectively enable/disable gnome-keyring components through autostart files because xfce4-session does not support early autostart files and modification of the session environment through DBus. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=710038 https://bugzilla.novell.com/show_bug.cgi?id=710038#c6 --- Comment #6 from Robert Schweikert 2011-09-01 14:22:04 UTC --- OK, have "working" but would like some input/review of my work-around. Starting the keyring daemon in .xinitrc somehow causes trouble for the nm_applet, as mentioned in the previous comment. Thus I decided to try the login shell, i.e. .login file for tcsh (which I run). In .login I know have the following: set gkeyd=/usr/bin/gnome-keyring-daemon set gkeydArgs="--start" set gkeydInfo=~/.gnome2/keyrings/daemon-info set countFile=~/.gnome2/keyrings/daemon-counter if ( -r $gkeydInfo ) source $gkeydInfo if ( $?GNOME_KEYRING_PID ) then set this=`ps -elf | grep ${GNOME_KEYRING_PID} | grep gnome-keyring-daemon > /dev/null` # start the daemon if it is not running if (( $? != 0 ) && ( -x "gkeyd" )) then $gkeyd $gkeydArgs | awk -F = '{print "setenv " $1 " " $2}' > $gkeydInfo echo "1" > $countFile source $gkeyInfo else set count=`cat ${countFile}` echo "$count + 1" | bc > $countFile endif else $gkeyd $gkeydArgs | awk -F = '{print "setenv " $1 " " $2}' > $gkeydInfo echo "setenv GNOME_KEYRING_COUNTER ${$countFile}" >> $gkeydInfo echo "setenv GNOME_KEYRING_INFO ${gkeydInfo}" >> $gkeydInfo echo "1" > $countFile source $gkeydInfo endif After I restart everything is working, ssh-agent, which I start separately in xinitrc as follows: eval `/usr/bin/ssh-agent -s` SSH_ASKPASS=/usr/lib64/ssh/ssh-askpass if test -S "$SSH_AUTH_SOCK" -a -x "$SSH_ASKPASS"; then ssh-add < /dev/null fi And the keyring is running. Better yet running an osc command it actually appears to use the keyring and I no longer get stupid "auth" errors. Now the problem. Although everything is running there was no ~/.gnome2/keyrings/daemon-info file and the daemon-counter was empty. Does the daemon somehow fiddle with the .gnome2/keyrings directory when it starts? I can certainly store the file somewhere else. Other comments/thoughts on this solution? I will test this for a while and if things work I'll write a blog on Lizards. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=710038 https://bugzilla.novell.com/show_bug.cgi?id=710038#c8 --- Comment #8 from Guido Berhörster 2011-09-01 14:32:21 UTC --- I would suggest the following workaround for now: 1. Open the Session settings: Settings -> Preferences -> Settings Manager -> Session and Startup 2. Enable GNOME compatibility mode: Go to Advanced, check "Launch GNOME services on startup" 3. Disable unwanted GNOME-only autostart files: Execute the following one-liner on the shell: for gnome_autostart in $(awk '/^OnlyShowIn=/ && /GNOME;/ && !/XFCE;/ { print FILENAME }' /etc/xdg/autostart/*); do : sed '$aHidden=true' ${gnome_autostart}

${HOME}/.config/autostart/${gnome_autostart##*/}; done

I'll talk to upstream later and see if we can move gnome-keyring support out of GNOME compatibility mode. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=710038 https://bugzilla.novell.com/show_bug.cgi?id=710038#c10 --- Comment #10 from Robert Schweikert 2011-09-02 16:21:03 UTC --- Thanks. Still having issues with osc, but these appear to be osc problems now as the environment is certainly set. ssh key management now works the same as it did when I was using GNOME. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=710038 https://bugzilla.novell.com/show_bug.cgi?id=710038#c12 --- Comment #12 from Guido Berhörster 2011-10-08 17:38:44 UTC --- I've just added a patch to the upstream bug which implements a part of the discussed GNOME compatibility modernization and also addresses this bug. Basically it removes obsolete parts of GNOME compatibility mode such as GNOME SMProxy compatibility and GConf shutdown. Furthermore it implements the discussed changes in how autostart files are treated, GNOME- or KDE-only files are now treated the same way as inactive files, they will not be unconditionally started in GNOME-/KDE-compatibility mode any more but are displayed in xfce4-session-settings and can be explicitly enabled. This way GNOME compat mode can be safely enabled to start gnome-keyring while potentially unwanted and harmful services such as gnome-settings-daemon or gnome-power-manager will not be started by default any more. xfce4-session packages which contain a backport of this patch are available for testing from home:gberh:branches:X11:xfce/xfce4-session. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=710038 https://bugzilla.novell.com/show_bug.cgi?id=710038#c14 Guido Berhörster changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #14 from Guido Berhörster 2011-10-14 11:39:25 UTC --- Fixed in Factory. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=710038 https://bugzilla.novell.com/show_bug.cgi?id=710038#c16 Guido Berhörster changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Component|Xfce |Xfce Version|RC 1 |Final Resolution| |FIXED Product|openSUSE 12.3 |openSUSE 11.4 --- Comment #16 from Guido Berhörster 2013-02-22 23:11:03 UTC --- (In reply to comment #15)

(In reply to comment #14)

...

Fixed in Factory.

it's back again in 12.3-RC1 (or never got fixed?) !

I'm using 12.3-RC1 plus updates and run XFCE4.

/usr/bin/gnome-keyring-daemon --daemonize --login

gets started and it's loading offering all my ssh-keys, which is a no-go!

when debugging my ssh-agent problems, I found the hint in some discussions to rename/remove nome-keyring-daemon (or remove execute permission).

this worked fine for me -- until bug #805048: NetworkManager needs gnome-keyring-daemon to ask for wifi passphrases :-((

so gnome-keyring-daemon is back in businees, and trashes my ssh usage:-(

looking for other solutions I found e.g. http://ubuntuforums.org/showthread.php?t=1655397

but

sudo gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --type bool --set /apps/gnome-keyring/daemon-components/ssh FALSE does not help.

https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/932177/comments...

does not work either for me, the key daemon still loads/offers all ssh keys (output of "ssh-add -l").

for now I've hacked the gnome-keyring-daemon to garble the path to my keys:

diff <( strings /usr/bin/gnome-keyring-daemon~ ) <( strings /usr/bin/gnome-keyring-daemon ) 9543c9543 < ~/.ssh ---

...

~/@ssh

but of corse that's not the way to go:-(

so my question for running XFCE4:

how can I disable the ssh-agent functionality for gnome-keyring-daemon these days ???

That's currently not possible, you can either start all components of gnome-keyring-daemon (by enabling GNOME compatibility mode) or not start it at all. This bug was about making it work properly at all which has been the case since 12.1. The ability to selectively enable/disable components is a different issue and would need to be addressed upstream. Please file a new enhancement request, preferably on the upstream tracker or here if you want me to forward it for you. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.