Description of problem: After preupgrading from Fedora 12 to Fedora 13, NetworkManager always asks for WLAN secrets. I'm using KDE, not GNOME, but previously gnome-keyring-daemon has provided those secrets. Version-Release number of selected component (if applicable): dbus-1.2.20-1.fc13.i686 gnome-keyring-2.29.90-2.fc13.i686 NetworkManager-0.8.0-0.4.git20100211.fc13.i686 How reproducible: Always Steps to Reproduce: 1. login to KDE 2. start nm-applet 3. connect to a protected WLAN Actual results: NM asks for passwords Expected results: NM should be able to get secrets from gnome-keyring-daemon Additional info: When I start nm-applet in a terminal I see these messages: ** Message: secret service operation failed: The name org.freedesktop.secrets was not provided by any .service files but when I search dbus files I see only this: $ find /usr/share/dbus-1/ -type f | xargs fgrep secrets /usr/share/dbus-1/services/org.gnome.keyring.service:Exec=/usr/bin/gnome-keyring-daemon --start --foreground --components=secrets Should NM fall back to org.gnome.keyring if org.freedesktop.secrets fails?
FYI: I changed /usr/share/dbus-1/services/org.gnome.keyring.service to read [D-BUS Service] #Name=org.gnome.keyring Name=org.freedesktop.secrets and now it NM gets it's passwords again...
Dan, it would be nice if you could apply the fix because it affects Xfce and LXDE as well and we really need the keyring daemon there.
NM doesn't really have anything to do with this, it just uses the gnome-keyring libraries which happen to use D-Bus these days. So the problem is likely in gnome-keyring itself; moving to there. For gnome-keyring maintainer: I'm not sure what the problem is here in the gnome-keyring code, but a D-Bus service can hold as many bus names as it wants, so the gnome-keyring daemon could claim *both* org.gnome.keyring and org.freedesktop.secrets, and then you install two separate service activation files, one for each service name, and stuff should work as expected.
Created attachment 410107 [details] patch to change dbus name (In reply to comment #1) > FYI: I changed /usr/share/dbus-1/services/org.gnome.keyring.service to read > > [D-BUS Service] > #Name=org.gnome.keyring > Name=org.freedesktop.secrets > > and now it NM gets it's passwords again... Works here too. Attached is a patch, that can be applied to the version currently in CVS. When trying so, I also noted, that there is a rpath issue and I need to add the snipped from: https://fedoraproject.org/wiki/Packaging/Guidelines#Removing_Rpath
If both dbus names are required for proper function, +1 to Dan's suggestions in comment #3
Tomáš, this is vitally important for the Xfce and LXDE spin, not sure about KDE. What are your plans here?
This is important for KDE too. Last time I tested knetworkmanager it was still not functional, i.e. for now your are stuck with NetworkManager-gnome on a KDE install.
slightly offtopic, but I'm also curious to know why the org.freedesktop.* namespace is being used here? Is there a xdg secrets spec so that other providers can conform to it?
*** Bug 575914 has been marked as a duplicate of this bug. ***
Bug 575914 refers to the same issue, which I'm going to close as a duplicate now. My findings were that the desktop file limits daemon autostarts only to Gnome and LXDE while users were running XFCE and others. This is also an upstream bug https://bugzilla.gnome.org/show_bug.cgi?id=610715 (plus https://bugzilla.gnome.org/show_bug.cgi?id=593772 explaining the "dead" gnome-keyring-daemon processes within the session and not cleaning themselves).
ok, seems to be (partially) bug #453880 all over again yes, kick out the OnlyShowIn please, marking as blocker.
I've backported two patches from upstream, see https://bugzilla.gnome.org/show_bug.cgi?id=611002 I originally thought the org.freedesktop.secrets dbus node is going to become a standardized way for secret storage service with differrent implementations in particular desktop environments. But looks like this is not going to happen in near future (heard rumours about KWallet providing the same functionality in the future) and certainly not yet for F13.
gnome-keyring-2.30.1-2.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/gnome-keyring-2.30.1-2.fc13
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
gnome-keyring-2.30.1-2.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update gnome-keyring'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/gnome-keyring-2.30.1-2.fc13
Tomasz, the update has the necessary karma to be sent to stable - can you please submit it to stable? Thanks.
(In reply to comment #16) > Tomasz, the update has the necessary karma to be sent to stable - can you > please submit it to stable? Thanks. I thought a critical path update requires one karma from a proventester and one by a non-proventester and then it's directly submitted to stable automatically... Or can this be turned of by disabling karma automatism?
gnome-keyring-2.30.1-2.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to comment #8) > slightly offtopic, but I'm also curious to know why the org.freedesktop.* > namespace is being used here? Is there a xdg secrets spec so that other > providers can conform to it? Yes. http://www.freedesktop.org/wiki/Specifications/secret-storage-spec