Launchpad has imported 15 comments from the remote bug at https://bugzilla.novell.com/show_bug.cgi?id=710038.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2011-08-03T13:53:37+00:00 Rschweikert wrote: When logging into a GNOME session gnome-keyring management is setup in such a way that both ssh key management is enabled and the osc commands find and access gnome-keyring. The keyring needs to be unlocked only once per session, after that osc commands can access the key and it is not necessary to store account credentials in $HOME/.oscrc The work around is to enable "Launch GNOME services on startup" in the "Advanced" tab of the "Session and Startup". However, this results in too many services running. Reply at: https://bugs.launchpad.net/gnome- keyring/+bug/932177/comments/0 ------------------------------------------------------------------------ On 2011-08-03T13:55:35+00:00 Rschweikert wrote: Adding information posted to opensuse-xfce list on this topic: Initial post: Hi, Just switched to Xfce recently and have run across a couple of things that appear to be start up service related when compared to GNOME. First, when building a package locally using osc, I end up with an "401 Authentication" error. Pocking around a bit this appears to be gnome- keyring related. However, I have gnome-keyring-daemon running and marked as "autostart". When I used GNOME I didn't do anything special, osc just worked. Anyone has any idea what I need to do to get the keyring usage working again? Second, also authentication related, I now need to enter my passphrase when using key-authenticated ssh login. I suppose GNOME by default starts an ssh agent thus that the passphrase only gets entered once? How do I accomplish this with Xfce. The "autostratup" has an entry for "SSH Key Agent". What am I missing? Follow up post: When I turn on "Launch GNOME services on startup" in the "Advanced" tab of the "Session and Startup" settings I can get the behavior back I am used to in GNOME, i.e. when I ssh to a machine for the first time I get a dialog box that lets me type in my passphrase. Once I do this the key is "unlocked" and I can log into any machine without needing to enter my passphrase again. However, enabeling this also means that I am running more stuff than I probably want. I compared the list of processes running with the GNOME services launced and without and compared them. However, nothing sticks out as providing this nice "unlock the key" feature. Thus I am not certain how to enable just that service to allow me to disable the "Launch GNOME services on startup" setting again. Guido's response: you shouldn't use that setting, g-k-d is started through the PAM module so that no additional password needs to be entered to unlock it. It also needs to be initialized from the session and I suspect something isn't working right there (either the xdg autostart or session startup script) but I haven't had the time to investigate it yet. Feel free to open a bug to track this, it'll be needed anyway for a SRU. Karl's response: Traditionally, I have in my .xinitrc: eval `ssh-agent -s` ssh-add ~/.ssh/identity ~/.ssh/id_rsa & which is ugly, and probably no longer needed, but "works". Reply at: https://bugs.launchpad.net/gnome- keyring/+bug/932177/comments/1 ------------------------------------------------------------------------ On 2011-08-09T10:21:06+00:00 Guido Berhoerster wrote: 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. Reply at: https://bugs.launchpad.net/gnome- keyring/+bug/932177/comments/2 ------------------------------------------------------------------------ On 2011-08-31T21:15:36+00:00 Rschweikert wrote: 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? In http://live.gnome.org/GnomeKeyring/Pam it is proclaimed that PAM looks for GNOME_KEYRING_CONTROL. Therefore my thought about getting things rolling in .login Thoughts? Reply at: https://bugs.launchpad.net/gnome- keyring/+bug/932177/comments/3 ------------------------------------------------------------------------ On 2011-08-31T22:33:30+00:00 Guido Berhoerster wrote: (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. Reply at: https://bugs.launchpad.net/gnome- keyring/+bug/932177/comments/4 ------------------------------------------------------------------------ On 2011-09-01T13:15:00+00:00 Rschweikert wrote: Well, one would think there must be some kind of work-around that lets me run gnome-keyring such that it is actually useful. The background here is that it really bothers me to have my password in plain text format stored in .oscrc and apparently the keyring is the solution to this. So I tried: eval `/usr/bin/gnome-keyring-daemon --daemonize` in my .xinitrc file. But the result was not pleasant. By the time the desktop was up and operational I had 3 gnome-keyring-daemon processes running, for whatever reason. How and why would that happen? The second undesirable side effect was that the nm_applet was running but it was not showing up in the panel and I was unable to connect to a network. The environment didn't appear to be completely setup either, the GPG and KEYRING environment variables were set but the SSH environment was not set. I'd like to find some way, however hacky it may be to get the keyring stuff running. This at least would keep me going until a better solution is available from Xfce upstream. Of course if there is yet another way to beat the osc authorization trap without running the keyring I am open to use that as well. Reply at: https://bugs.launchpad.net/gnome- keyring/+bug/932177/comments/5 ------------------------------------------------------------------------ On 2011-09-01T14:22:04+00:00 Rschweikert wrote: 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. Reply at: https://bugs.launchpad.net/gnome- keyring/+bug/932177/comments/6 ------------------------------------------------------------------------ On 2011-09-01T14:23:00+00:00 Rschweikert wrote: Argh, and one more thing. Is there any reason I should kill the keyring daemon on logout? Reply at: https://bugs.launchpad.net/gnome- keyring/+bug/932177/comments/7 ------------------------------------------------------------------------ On 2011-09-01T14:32:21+00:00 Guido Berhoerster wrote: 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. Reply at: https://bugs.launchpad.net/gnome- keyring/+bug/932177/comments/8 ------------------------------------------------------------------------ On 2011-09-01T14:35:59+00:00 Guido Berhoerster wrote: There's a typo, the one liner should read: 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 Reply at: https://bugs.launchpad.net/gnome- keyring/+bug/932177/comments/9 ------------------------------------------------------------------------ On 2011-09-02T16:21:03+00:00 Rschweikert wrote: 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. Reply at: https://bugs.launchpad.net/gnome- keyring/+bug/932177/comments/10 ------------------------------------------------------------------------ On 2011-10-04T14:01:04+00:00 Guido Berhoerster wrote: After discussing this with upstream (see http://thread.gmane.org/gmane.comp.desktop.xfce.devel.version4/19646) there is now a RFE on the Xfce bugzilla. The proposed solution is to remove an explicit GNOME compatibility mode and the code currently associated with it and to add support for GNOME autostart phases to xfce4-session. Reply at: https://bugs.launchpad.net/gnome- keyring/+bug/932177/comments/11 ------------------------------------------------------------------------ On 2011-10-08T17:38:44+00:00 Guido Berhoerster wrote: 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. Reply at: https://bugs.launchpad.net/gnome- keyring/+bug/932177/comments/12 ------------------------------------------------------------------------ On 2011-10-14T00:00:10+00:00 Bwiedemann wrote: This is an autogenerated message for OBS integration: This bug (710038) was mentioned in https://build.opensuse.org/request/show/87771 Factory / xfce4-session Reply at: https://bugs.launchpad.net/gnome- keyring/+bug/932177/comments/13 ------------------------------------------------------------------------ On 2011-10-14T11:39:25+00:00 Guido Berhoerster wrote: Fixed in Factory. Reply at: https://bugs.launchpad.net/gnome- keyring/+bug/932177/comments/14 ** Changed in: gnome-keyring (openSUSE) Status: Unknown => Fix Released ** Changed in: gnome-keyring (openSUSE) Importance: Unknown => Medium -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-keyring in Ubuntu. https://bugs.launchpad.net/bugs/932177 Title: WARNING: gnome-keyring:: couldn't connect to PKCS11 Status in GNOME keyring services: Fix Released Status in “gnome-keyring” package in Ubuntu: Confirmed Status in “gnome-keyring” package in Debian: New Status in “gnome-keyring” package in Fedora: Unknown Status in “gnome-keyring” package in openSUSE: Fix Released Bug description: precise + fluxbox (without gnome-settings-daemon) Postler when sending a message writes: Failed to send a message WARNING: gnome-keyring:: couldn't connect to: /tmp/keyring-rof1VB/pkcs11: No such file or directory In gnome-system-monitor: /usr/bin/gnome-keyring-demon --start --foreground --components=secrets /usr/bin/gnome-keyring-demon --daemonize --login with manual start this: OK /usr/bin/gnome-keyring-daemon --start --components=pkcs11 Is it possible to add a string key '--components=pkcs11', so that the gnome-system-monitor was: /usr/bin/gnome-keyring-demon --start --foreground --components=secrets --components=pkcs11 thanks in advance... ProblemType: Bug DistroRelease: Ubuntu 12.04 Package: gnome-keyring 3.2.2-2ubuntu1 ProcVersionSignature: Ubuntu 3.2.0-15.24-generic 3.2.5 Uname: Linux 3.2.0-15-generic x86_64 ApportVersion: 1.91-0ubuntu1 Architecture: amd64 Date: Tue Feb 14 17:47:35 2012 InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100429) ProcEnviron: PATH=(custom, no user) LANG=ru_UA.UTF-8 SHELL=/bin/bash SourcePackage: gnome-keyring UpgradeStatus: Upgraded to precise on 2012-02-10 (3 days ago) mtime.conffile..etc.xdg.autostart.gnome.keyring.gpg.desktop: 2012-02-14T14:17:23.632015 mtime.conffile..etc.xdg.autostart.gnome.keyring.pkcs11.desktop: 2012-02-14T14:17:23.632015 mtime.conffile..etc.xdg.autostart.gnome.keyring.secrets.desktop: 2012-02-14T14:17:23.632015 mtime.conffile..etc.xdg.autostart.gnome.keyring.ssh.desktop: 2012-02-14T14:17:23.636015 To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-keyring/+bug/932177/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
