XFCE (and other non-GNOME) desktops do not initialise gnome-keyring correctly / WARNING: gnome-keyring:: couldn't connect to PKCS11

[Pavlo Bohmat]

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

[Rschweikert (rschweikert)]

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.

[Rschweikert (rschweikert)]

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

[Guido Berhoerster (gber)]

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.

[Rschweikert (rschweikert)]

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?

[Guido Berhoerster (gber)]

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

[Rschweikert (rschweikert)]

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.

[Rschweikert (rschweikert)]

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.

[Rschweikert (rschweikert)]

Argh, and one more thing. Is there any reason I should kill the keyring daemon on logout?

[Guido Berhoerster (gber)]

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.

[Guido Berhoerster (gber)]

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

[Rschweikert (rschweikert)]

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.

[Guido Berhoerster (gber)]

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.

[Guido Berhoerster (gber)]

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.

[Bwiedemann (bwiedemann)]

This is an autogenerated message for OBS integration:
This bug (710038) was mentioned in
https://build.opensuse.org/request/show/87771 Factory / xfce4-session

[Guido Berhoerster (gber)]

Fixed in Factory.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Ubuntu QA Website (ubuntuqa)]

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/932177

[Ulf Rehmann (rehmann)]

For me, the problem does occur for movemail in emacs since an upgrade to precise last night:

movemail: gnome-keyring:: couldn't connect to: /tmp/keyring-dq8XqX/pkcs11: No such file or directory

System: Ubuntu 12.04
Packages: dpkg -l | grep gnome-keyring
ii gnome-keyring 3.2.2-2ubuntu2 GNOME keyring services (daemon and tools)
ii libgnome-keyring-common 3.2.2-2 GNOME keyring services library - data files
ii libgnome-keyring0 3.2.2-2 GNOME keyring services library
ii libpam-gnome-keyring 3.2.2-2ubuntu2 PAM module to unlock the GNOME keyring upon login

There is a similar report at Debian:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649408

[Unit 193 (unit193)]

As found in one upstream bug, you can use a temporary fix/workaround for Xfce by doing
sudo sed -i.bak 's/OnlyShowIn=GNOME;Unity;/OnlyShowIn=GNOME;Unity;XFCE;/g' /etc/xdg/autostart/gnome-keyring-*.desktop
Then logging out and back in.

[Alvin (alvin)]

Running 12.04 w/ gnome-shell

see this bug everytime I use git to clone a repository -- sometimes preventing the ability to do so it authentication is required

happy to help anyone debug the issue -- competent with python haven't done much of anything with C

have already tried removing and re-installing gnome-keyring to no avail

[Krishna E. Bera (keb)]

Further to comment #5 above, i run Lubuntu 12.04 so i appended the string "LXDE;Lubuntu;" to the offending lines and the warning went away.

[Ben Hearsum (bhearsum)]

I just started hitting this in Ubuntu 12.04, running 'awesome'. When I try to launch gnome-setting-daemon I get:
➜ ~ gnome-settings-daemon
WARNING: gnome-keyring:: couldn't connect to: /tmp/keyring-AASi0t/pkcs11: No such file or directory

** (process:1884): WARNING **: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service files

** (gnome-settings-daemon:1878): WARNING **: Unable to register client: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service files
[1337166217,000,xklavier.c:xkl_engine_start_listen/] The backend does not require manual layout management - but it is provided by the application

[Ben Hearsum (bhearsum)]

The instructions in this forum post effectively worked around the issue for me: http://ubuntuforums.org/showpost.php?p=10301640&postcount=8

[superxor (phaneendra-chiruvella)]

I've started facing this problem. I am using Ubuntu 12.04 with 'Awesome' window manager. Keeps appearing when I am trying to use Git to clone/push/pull.

[yitzhakbg (yitzhakbg)]

On Wed, 16 May 2012 12:17:36 -0000
Ben Hearsum <email address hidden> wrote:

> The instructions in this forum post effectively worked around the issue
> for me: http://ubuntuforums.org/showpost.php?p=10301640&postcount=8
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/932177
>
> Title:
> WARNING: gnome-keyring:: couldn't connect to PKCS11
>
> Status in “gnome-keyring” package in Ubuntu:
> Confirmed
> Status in “gnome-keyring” package in Debian:
> New
> Status in “gnome-keyring” package in Fedora:
> Unknown
>
> 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/ubuntu/+source/gnome-keyring/+bug/932177/+subscriptions
Thanks

[Chris Bainbridge (chris-bainbridge)]

I was interested in the correct solution rather than the workaround of manually reverting the changes to gnome-keyring's /etc/ config. I asked Guido Berhoerster, and he said:

"if you are not running gnome-session then gnome-keyring-daemon cannot be correctly initialized through the XDG autostart mechanism because the necessary environment variables cannot be set for your session (see my detailed explanation at https://bugzilla.novell.com/show_bug.cgi?id=710038#c2). So what that basically means is that whether you initialize gnome-keyring through XDG autostart or not does not make any difference outside GNOME because it will be inaccessible from your session.

In order to use gnome-keyring with Xfce you need to enable "GNOME compatibility mode", if you use something else you need to modify your session wrapper so that it calls "gnome-keyring-daemon --start", reads its output and exports the printed environment variables. That assumes of course that gnome-keyring-daemon has been correctly started and unlocked via PAM.

...starting with openSUSE 12.2 gnome-keyring will be installed and enabled by default. It is also possible to use gnome-keyring with Xfce on openSUSE 12.1 since we patch xfce4-session to avoid undesirable side effects of GNOME compat mode in Xfce 4.8 (https://bugzilla.xfce.org/show_bug.cgi?id=8014#c0), however GNOME compatibility mode needs to be enabled manually.

Making it work is relatively simple starting with Xfce 4.10 you just need to follow https://live.gnome.org/GnomeKeyring/Pam and enable GNOME compat mode.

For Xfce 4.8 it is more complicated because xfce4-session would need to be patched with backports of commit 0fea8c64bfc32915d9e397e7029de150167a737d and 67b772364c9e9a7ea9cc4dafb219902c6c8b074a in order to make GNOME compat mode usable."

[Chris Bainbridge (chris-bainbridge)]

Another comment from Guido regarding modifying the /etc/ autostart files:

"What happens is that if gnome-keyring components are not initialized through XDG autostart any more they will be DBus-activated (see https://live.gnome.org/GnomeKeyring/RunningDaemon). So when they start adding back the autostart files for them the warnings will disappear because there will be no DBus-activation but the SSH/GPG components will not magically start working outside GNOME. So the only bug here is that these people are trying to use GNOME keyring without initializing it properly using the methods I've described before."

[Eric S Fraga (e-fraga)]

I just wanted to add (or confirm) that adding the following line to my .xsession file

eval $(gnome-keyring-daemon --start)

allows me to get this working with ratpoison or fluxbox as my window managers.

[Sebastien Bacher (seb128)]

Thanks for the details, the fact it's a affecting non GNOME session only explains why most people around don't get the issue

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Sebastien Bacher (seb128)]

suggested upstream xfce patch on https://bugzilla.xfce.org/attachment.cgi?id=3953&action=diff

[Lionel Le Folgoc (mrpouit)]

This should be fixed with xfce4-session 4.10 (in quantal), but gnome-compat needs to be reenabled by default now (Bug #1008993).

[superxor (phaneendra-chiruvella)]

I got an other workaround for the bug from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649408#109

Open /etc/pkcs11/modules/gnome-keyring-module and comment out the line "module: gnome-keyring-pkcs11.so".

[Gary Kline (kline)]

This gnome WARNING has been bothering me for weeks. but now my Brother HL-3040CN printer fails and the string is issured more frequently:

WARNING: gnome-keyring:: couldn't connect to: /tmp/keyring-vlN7D3/pkcs11: No such file or directory

Following the suggestion directly above makes the WARNING go away, but the printer is still messed up.

[Antti Kaihola (akaihola)]

Any permanent fix planned for Lubuntu/LXDE?

[Balaji G (balajig81)]

I get this problem still. I am running XFCE 4.10 and i see the error when i do git clone or git pull. Following is the error

"git pull
WARNING: gnome-keyring:: couldn't connect to: /tmp/keyring-ySN77r/pkcs11: No such file or directory
Already up-to-date.
"

[circularfile (circularfile)]

I found a nice solution to this problem at
http://hongouru.blogspot.fr/2012/07/sol … uldnt.html

In my case I add MATE instead of LXDE.
I believe those working with Mint have to add Mint or MINT.

[Andrey Bondarenko (abone)]

In my opinion, for Ubuntu-based distributions the root cause of the bug is in lightdm package. At least, in quantal it becomes default display manager for all desktops including non-GNOME ones.

In files:
 * /etc/pam.d/lightdm
 * /etc/pam.d/lightdm-greeter

it has the following line:

session optional pam_gnome_keyring.so auto_start

The line starts gnome-keyring daemon for all desktops, while only few of them can properly set up gnome-keyring right now.
Probably only_if argument should be used, so keyring daemon will start only for supported environment.

One possible workaround is to switch from lightdm to DE speciffic display manager which don't start gnome-kering
at all.

[Ma Hsiao-chun (mahsiaochun)]

@abone
Nice observation!
I'm using MATE.
I once noted that when LightDM is running, there are g-s-d and gnome-keyring processes.
After entering MATE session, gnome-keyring is still there.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[oleibrock (oliver-leibrock)]

I ran into same issue after I removed my ecrypt'ed $HOME and tried to start
conky & some apps using wine.

$ conky -c /home/xxxxx/.conky/conky-autostart
WARNING: gnome-keyring:: couldn't connect to: /tmp/keyring-YiWUvh/pkcs11: No such file or directory

I use UbuntuStudio 12.04.1 LTS ; lightdm ; xfce 4.8.

I do only see a gnome-keyring-daemon process.

I followed the workaround with /etc/pkcs11/modules/gnome-keyring-module
file edit, which did not solve it either.

[Julián Landerreche (maniqui)]

I ran into this issue when tried to run "git svn fetch" on a repo I've cloned just a few seconds previously (which prompted me from username & password).

$ git svn fetch
WARNING: gnome-keyring:: couldn't connect to: /home/xxxxx/.cache/keyring-6DeUlo/pkcs11: No such file or directory

The workaround in comment #34 worked for me on Debian Wheezy + XFCE 4.8: the warning is not being printed on screen. Of course, I'm not sure yet about what side issues this workaround could have introduced. Any ideas?

[Chris Bainbridge (chris-bainbridge)]

@Julián the only problem is that gnome-keyring won't actually work (see comment #27), but if you don't use it, and none of the apps you use rely on it, then that won't affect you.

[Stephen G (stephengroat)]

I'm on precise and using ldap auth along with local auth. I only get the error on ldap auth

[J-koenig (j-koenig)]

(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/20

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

thanks for the real[tm] solution!!!

[Guido Berhoerster (gber)]

(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/20
>
> 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.

[martin suchanek (martin-suc)]

does exist any solution which works as for desktop as for terminal commands ?

[RichardNeill (ubuntu-richardneill)]

I'd like to confirm this bug for KUbuntu Raring Beta-final. Please fix it; it's most definitely not invalid.

To reproduce:

1. Install both sets of desktops: apt-get install ubuntu-desktop kubuntu-desktop
2. Log into a KDE session.
3. launch an application from the terminal "eg libre-office".
4. Observe that it complains about "WARNING: gnome-keyring:: couldn't connect to PKCS11"

To solve it:

1. Edit the file: /etc/xdg/autostart/gnome-keyring-pkcs11.desktop
2. Append KDE to the line: "OnlyShowIn=GNOME;Unity;MATE;KDE;"

or, uninstall gnome-keyring entirely.

[Luigi Calligaris (luigi-calligaris)]

I can confirm the bug in Kubuntu 13.04, where the upgrade from 12.10 overwrote the file

/etc/xdg/autostart/gnome-keyring-pkcs11.desktop

in which I had previously applied a fix as the one described by RichardNeill, i.e. appending "KDE;" to the line "OnlyShowIn=GNOME;Unity;MATE;"

[Paul White (paulw2u)]

Also in Kubuntu 13.10.

Have added "saucy" and "kubuntu" to tags so that bugs reports might be received by those that can apply or push for a fix.

[Timothy Gu (timothy-gu)]

Reproducible in Lubuntu 13.04.

[Fitzhugh (launchpad-inb)]

Reproducible in xubuntu 13.04.

[Chris Bainbridge (chris-bainbridge)]

This is actually a security bug for users of Chrome / Chromium. Chrome will store passwords in cleartext if gnome-keyring isn't functional. This is mentioned in the upstream Chrome disk encryption bug
https://code.google.com/p/chromium/issues/detail?id=25404

$ cp ~/.config/chromium/Default/Login\ Data x.db
$ sqlite3 x.db
sqlite> SELECT username_value, password_value FROM logins;
billg|passw0rd
sqlite>

[Andrey Bondarenko (abone)]

As the bug is still present in 13.04 and probably 13.10 Kubuntu users may be interested in a workaround:

Copy the attached script 01gnome-keyring-daemon.sh into ~/.kde/env directory.

Files in this directory are sources by /usr/bin/startkde so the script can finish gnome-keyring-daemon initialization and provide environment variables for KDE session.

[Ron Johnson (ron-l-johnson)]

Confirmed in xubuntu 13.04. The OnlyShowIn modification works.

[dotancohen (dotancohen)]

I can confirm that the script in comment #55 resolves the issue in Kubuntu 12.10, and does not seem to contain malicious content. Note that it must be mae executable, i.e. "chmod +x".

[Petar Sredojevic (perosredo)]

Confirmed with Chromium on 14.04.

[cousteau (cousteaulecommandant)]

It's 2014, this bug is already 2 years old, and hasn't been fixed yet,
at least on Xubuntu 12.04. Fixing it seems trivial.

Possible solutions:

1. If the package gnome-keyring is not needed on Xubuntu (or other
   affected Ubuntu flavors), it should be considered to be removed from
   it as a default package so that other applications don't try to
   connect to it.

2. If the package gnome-keyring is required, it should be fixed so that
   it runs properly on all the Ubuntu flavors that use it. The problem
   seems to be in /etc/xdg/autostart/gnome-keyring-pkcs11.desktop which
   is only enabled for Gnome and Unity.
   2.1. Fix the line OnlyShowIn=GNOME;Unity;
        2.1.1. by appending XFCE;KDE;LXDE; and any other DE that may
               need or use pkcs11.
        2.1.2. by deleting or commenting out that line so that all DEs
               may use it (if anything, add a NotShowIn=... blacklist
               for DEs in which this may cause problems).
   2.2. Make XFCE include an identical .desktop file with
        OnlyShowIn=XFCE; in it, so that the fix for XFCE is independent
        from other DEs.
   2.3. Make XFCE load all Gnome services at startup by default (which
        may also include some unwanted stuff and thus may not be a good
        idea).

3. If the package gnome-keyring is required due to dependencies, but
   the service pkcs11 is not needed for it and other applications to
   run properly, the warning message it displays should be removed.
   3.1. Making gnome-keyring not display that warning.
   3.2. Making gnome-keyring inform applications that the service
        pkcs11 is unavailable.
   3.3. Making all applications that use gnome-keyring check whether
        the service pkcs11 is available before requesting it (which
        would imply fixing them one by one, which may be a bad idea).

[isomorphismes (isomorphismes)]

I have this problem in R using the jsonlite package. Ubuntu 12.04 i686. Using awesome window manager.

[Yanpas (yanpaso)]

Facing the same. gnome-keyring-daemon often fails to start, if it manages to start it asks for Login keyring password.

BTW gnome-keyring-daemon always starts from root, even if I run it from user in terminal!

xubuntu 16.04, it became broken in these two months.

[aj duncan (a-duncan)]

The solutions here did not work in my case, but a solution which did work for me can be found in
https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/1022322
which says:

The file causing the problem is /etc/xdg/autostart/gnome-keyring-pkcs11.desktop . The line
OnlyShowIn=GNOME;Unity
should be changed to
OnlyShowIn=GNOME;Unity;XFCE

There are similar statements above, but none include XFCE.

[aj duncan (a-duncan)]

.... now I've made the comment I see the solution is to be found in this page ... sorry.