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 747359 - secret_service_search with UNLOCK flag returns hashed attributes if the keyring is locked before the search
secret_service_search with UNLOCK flag returns hashed attributes if the keyri...
Status: RESOLVED OBSOLETE
Product: libsecret
Classification: Other
Component: General
unspecified
Other Linux
: Normal normal
: ---
Assigned To: libsecret maintainer(s)
libsecret maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2015-04-05 07:35 UTC by Sami Jaktholm
Modified: 2018-09-21 16:24 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
secrets-testcase.c - a sample program to see this problem in action (1.29 KB, text/x-csrc)
2015-04-05 07:35 UTC, Sami Jaktholm
Details

Description Sami Jaktholm 2015-04-05 07:35:49 UTC
Created attachment 300973 [details]
secrets-testcase.c - a sample program to see this problem in action

Steps to reproduce:
0. Have an network-manager stored connection secret in your keyring. One can be obtained by creating new Wi-Fi connection with nm-connection-editor that's not available to all users and uses "WPA & WPA2 PSK" security. It doesn't really matter what the item is but the testcase searches for network-manager secrets.
1. Restart gnome-keyring-daemon to flush any data that might already be decrypted.
    gnome-keyring-deamon --replace --components secrets
2. Download the attached testcase and compile it:
    gcc secrets-testcase.c -o secrets-testcase `pkg-config --cflags --libs libsecret-1`
3. Run the testcase, unlock the keyring when prompted:
    ./secrets-testcase
4. Run the testcase again:
    ./secrets-testcase

What happens:

The output after step three looks like (attributes are hashes):
Found item
>   attributes:
>     gkr:compat:hashed:connection-uuid: 85c4d5896f5f532c079d07ac5fb42336
>     gkr:compat:hashed:setting-key: 797633604dd0ac41f2a7fc6d0be64f22
>     gkr:compat:hashed:setting-name: d4e1f4563c931c53dba89c06acb04541
>     gkr:compat:hashed:xdg:schema: ec1bf9e891d588ba34f4d1227c6463ee
>     xdg:schema: org.freedesktop.Secret.Generic

The output after step four looks like (attributes are correct):
> Found item Network secret for wifi/802-11-wireless-security/psk
>   attributes:
>     xdg:schema: org.freedesktop.NetworkManager.Connection
>     setting-name: 802-11-wireless-security
>     setting-key: psk
>     connection-uuid: 5149d016-df2c-4f96-8f87-96c733634064

What should happen: The output at step three should be identical to step four.

This causes an annoying issue with network-manager-applet which relies on the attributes to be always available. If you try to connect to a network that requires secrets from a locked keyring, the attempt fails as the attributes are hashed. It only succeeds on the second try.

I've reproduced this on Ubuntu 14.04 with versions 0.16 and 0.18 of libsecret and version 3.10.1 of gnome-keyring. I'll try to test this with a newer gnome-keyring next week.
Comment 1 GNOME Infrastructure Team 2018-09-21 16:24:58 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/6.