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 748625 - secret_password_lookup_sync doesn't ask to unlock
secret_password_lookup_sync doesn't ask to unlock
Status: RESOLVED OBSOLETE
Product: libsecret
Classification: Other
Component: General
0.18.x
Other Linux
: Normal normal
: ---
Assigned To: libsecret maintainer(s)
libsecret maintainer(s)
Depends on:
Blocks: 746873
 
 
Reported: 2015-04-29 10:31 UTC by Geert Janssens
Modified: 2018-09-21 16:25 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Testcase to illustrate the issue (2.00 KB, application/x-compressed-tar)
2015-04-29 10:31 UTC, Geert Janssens
Details

Description Geert Janssens 2015-04-29 10:31:28 UTC
Created attachment 302551 [details]
Testcase to illustrate the issue

I'm using the simple api in my application to lookup passwords from the secret service. This works fine if the keyring is unlocked but fails if it is not.

Attached is a simple test case to illustrate my issue.

What probably matters is that I'm running into this issue when using the application from a kde environment, in which gnome-keyring-daemon is not launched and unlocked at startup. When running I am killing gnome-keyring-daemon before running the tests to reproduce this issue.

The test has two executables:
- libsecret-test-store -> will store a password in the secret service to be retrieved with the second executable

- libsecret-test-get -> will attempt to lookup a password using the simple api.

libsecret-test-store is only added to store an initial password so we can test retrieval with the second executable. Storing works fine regardless of whether gnome-keyring-daemon was running or not. If the daemon isn't running it will start the daemon. If the keyring is (still) locked it will prompt for a password to unlock. 

The second executable can be used to illustrate my issue once a password has been stored. Running it immediately after storing the password will work correctly (because the keyring is still unlocked).

Locking the keyring using seahorse and then running libsecret-test-get will make it prompt for a password to unlock and then successfully retrieve the stored password.

However after killing gnome-keyring-daemon, the second executable won't find the password. It won't even ask for a password to unlock the keyring. It does start the gnomne-keyring-daemon though.

I expected the simple API would do what is needed to lookup the password, including unlocking the keyring if that's required to find the password. Is that a wrong assumption ?
Comment 1 cfroussios 2016-11-09 15:01:20 UTC
This sounds like the same problem we ran into in the Chromium project.
http://crbug.com/660005

It appears that, when retrieving entries, keyrings will be ignored if:
1. The keyring has never been unlocked since the start of the session.
2. The keyring has never been unlocked since its password was changed.

Unlocking and re-locking the keyring does not reproduce the bug.
Comment 2 GNOME Infrastructure Team 2018-09-21 16:25:11 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/libsecret/issues/7.