After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 476644 - Unable to user keyring for new users with pidgin
Unable to user keyring for new users with pidgin
Status: RESOLVED FIXED
Product: gnome-keyring
Classification: Core
Component: general
2.19.x
Other All
: Normal blocker
: ---
Assigned To: GNOME keyring maintainer(s)
GNOME keyring maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2007-09-13 17:52 UTC by Darren Kenny
Modified: 2007-10-06 14:23 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20


Attachments
Patch to fix the issues. (1.28 KB, patch)
2007-09-13 17:53 UTC, Darren Kenny
committed Details | Review

Description Darren Kenny 2007-09-13 17:52:20 UTC
Please describe the problem:
For a new user, without the ${HOME}/.gnome2/keyrings directory, using the latest sources for 2.19, using something like pidgin to open the default keyring results in constant prompts for the creation of a new keyring, and the production of several default.keyring and defaultN.keyring files.

This is happening on Solaris where the user doesn't have the permission to uses shared memory.

Steps to reproduce:
rm -rf ${HOME}/.gnome/keyrings
pidgin &

Actual results:
Multiple questions for password to create new default keyring.

Expected results:
Only get asked once

Does this happen every time?
Yep

Other information:
I have a patch, that I'll attach. There are two issues:

1) Freeing the display_name that's stored in the GkrKeyring, should be strduped() - this resulted in some corruption of the structure, at times.
2) On creation of a new keyring it should be added to the list of known keyrings, this happens in one case, but there is another case where it isn't and a such we can never find the default keyring.
Comment 1 Darren Kenny 2007-09-13 17:53:12 UTC
Created attachment 95533 [details] [review]
Patch to fix the issues.
Comment 2 Stef Walter 2007-09-13 19:19:32 UTC
Thanks for taking the time to look into the problem.

Issue #1: Not sure why this is a problem. Could you describe this further? The very next line zeros out the display_name pointer thus the ownership of the memory has effectively been transferred. 

Issue #2: Good catch. I'll commit this once GNOME is out of its hard code freeze. On most systems the fact that gnome-keyring-daemon automatically loads any new files in its directory mitigates this problem. Not sure why it isn't doing this for you, but it's a bug none the less.

Comment 3 Darren Kenny 2007-09-14 11:02:18 UTC
Hmm, you're right about issue 1 - sorry, missed the NULL assignment... Not sure what I saw then... 

As for the reading of the directory element, I can see where that happens in the code, not sure why that didn't find it, maybe the subject of further investigation there!

Thanks.



Comment 4 Stef Walter 2007-09-23 23:08:00 UTC
Committed the first part of your patch.
Comment 5 Stef Walter 2007-10-04 14:29:18 UTC
*** Bug 483288 has been marked as a duplicate of this bug. ***
Comment 6 Sebastien Bacher 2007-10-06 09:52:09 UTC
http://svn.gnome.org/viewcvs/gnome-keyring?view=revision&revision=840 only mentions a changelog commit, is that normal?
Comment 7 Sebastien Bacher 2007-10-06 09:53:03 UTC
ok, looks like the code change is an another commit
Comment 8 Stef Walter 2007-10-06 14:23:04 UTC
Yes, my goof. For the record: Changeset 839 is the code, Changeset 840 the Changelog to go with it.