Description of problem: When you log in with kdm, the modules for gnome-keyring are not executed. This makes it impossible to start up things like gnome mail notification. The pam modules that are executed for gdm are not executed for kdm Version-Release number of selected component (if applicable): How reproducible: Start up gnome session logging in with kdm install gnome-mail-notification try to add new mailbox to mail notification the addition is rejected login through gdm everything seems to work Steps to Reproduce: 1. 2. 3.
it's impossible to solve this currently in fact, there's two things differents: - launch gnome-keyring on start, you could do that by yourself. - use of ksecretservices, where kwallet & gnome-keyring will be able to « share » secrets so a gnome-app would not requires gnome-keyring to be started (since kwallet should provides the necessary data but it's not expected until KDE Platform 4.8) thanks to mikala for the explain
(In reply to comment #1) > it's impossible to solve this currently in fact, there's two things differents: > - launch gnome-keyring on start, you could do that by yourself. > - use of ksecretservices, where kwallet & gnome-keyring will be able to « share > » secrets so a gnome-app would not requires gnome-keyring to be started > (since kwallet should provides the necessary data but it's not expected until > KDE Platform 4.8) > thanks to mikala for the explain on kde.org it says: "KDE Makes 4.8 Beta1 Available for Testing On 24th November 2011, KDE has released Beta1 of the 4.8 releases, to become final in January 2012." @ Mikala I changed the rpm to kwallet, is that correct? Assigning to you
CC: (none) => marja11Assignee: bugsquad => balcaen.johnSource RPM: pam-1.1.3-3.mga2 => kwallet
I would say no. Here the user is launching gnome *via* kdm & not launching a gnome app under kde. The ksecretservice is supposed to solve this situation (thought it won't be enable by default on kde 4.8 regarding the last mail i read) In this case Joseph simply use kdm to launch gnome. so he's supposed to run a full gnome session, however it seems that gnome does not launch gnome-keyring when it should. So the fix should be done in the gnome startup script & not in kwallet/kdm. Seems like when i explain the ksecretservice functionnality i did not read correctly this bug report. Reassiging to bugsquad ;o)
CC: (none) => balcaen.johnAssignee: balcaen.john => bugsquadSource RPM: kwallet => (none)
assigning to the maintainer of gnome-keyring (and of more gnome)
Assignee: bugsquad => olavSource RPM: (none) => gnome-keyring
From what I understood, there is some kind of freedesktop.org standard to share the keyring. So GNOME applications should make use of the existing keyring infrastructure (KDE). Assining to manuel as I hope he knows more..
Assignee: olav => manuel
>Assining to manuel as I hope he knows more.. nop :) my exploitation was a copy paste from irc in fact so we will keep this bug in this state, sorry joseph
Assignee: manuel => bugsquad
s/exploitation/explanation
Hi, This bug was filed against cauldron, but we do not have cauldron at the moment. Please report whether this bug is still valid for Mageia 2. Thanks :) Cheers, marja
Keywords: (none) => NEEDINFO
Ping! It is very important for us to know whether this bug is still valid for Mageia 2 or for *current* cauldron (so from after Mageia 2 was released). Please tell us. If you don't reply, we'll have to close this bug as old.
Well it's going to be still valid since - we do not provides ksecrets for 4.8.x (it's quite difficult to build/use it ) - gnome needs also to migrate to this kind of security scheme (it's expected for 3.6 but i'm not sure). How ever it's an « upstream » work in progress so nothing we can really do (except for the work around mentionned earlier).
(In reply to comment #10) > Well it's going to be still valid since > - we do not provides ksecrets for 4.8.x (it's quite difficult to build/use it ) > - gnome needs also to migrate to this kind of security scheme (it's expected > for 3.6 but i'm not sure). > > How ever it's an « upstream » work in progress so nothing we can really do > (except for the work around mentionned earlier). Thx John :) I wouldn't mind if someone would add a relevant link to upstream to this report
Keywords: NEEDINFO => UPSTREAMWhiteboard: (none) => MGA2TOO
Should this stay open?
CC: (none) => nic
(In reply to Nic Baxter from comment #12) > Should this stay open? If it did get fixed then I suppose it can easily get broken again. Anyway, no one ever gave a link to an upstream bug report, nor did anyone reply to your question, so closing as OLD
Status: NEW => RESOLVEDResolution: (none) => OLD