Skip to content

KeepassXC as libsecret implementation doesn't return secret when searching by some attributes #3729

@neanox

Description

@neanox

Expected Behavior

When using the secret-tool to search for a secret value by the attribute "setting-name", the gnome-keyring implementation of libsecret returns the secret:
Screenshot from 2019-10-30 06-35-36
I have included seahorse in the screenshot, as it seems to have no problems accessing either gnome-keyring or KeepassXC.

The secret was created by gnome when it tried to store a vpn password into the keyring. It was successfully stored in both gnome-keyring and KeepassXC. The expected behaviour from KeepassXC would be to return the secret in the same way.

Current Behavior

When using the secret-tool, running the same command, to search for a secret created in the same way, by the attribute "setting-name", KeepassXC returns nothing:
Screenshot from 2019-10-30 06-39-28

The secret stored in KeepassXC seems to have a few extra attributes, but as far as I understand, that shouldn't be a problem. The attributes in the database:
Screenshot from 2019-10-30 06-40-05

I have tried searching by other attributes, and the ones that seem to work are:

  • Title
  • Uuid
  • URL (with just an empty string)
  • UserName (again, with an empty string)

The ones that don't work (that I have tried) are:

  • setting-key
  • setting-name
  • connection-uuid

If I create a secret with the attribute "setting-name" manually, secret-tool doesn't retrieve it from KeepassXC either. If I create one with the attribute settingname, it is retrieved.

Possible Solution

From what I have tried, it seems that some characters in attribute keys can prevent them from being retrieved by secret-tool.

Steps to Reproduce

  1. Set up an arch-linux operating system with packages libsecret-0.19.1-1 and KeepassXC-2.5.0-2
  2. Create a database and enable Secret Service Integration, exposing the database
  3. Run "secret-tool store --label testworking settingname name" to store a working example
  4. Run "secret-tool store --label testnotworking setting-name name" to store a non-woring example
  5. Run "secret-tool search --all settingname name" to see a working example
  6. Run "secret-tool search --all setting-name name" to see a non-working example

Note: I am using the gnome3 desktop environment.

Context

I was trying to figure out why gnome keeps asking for the password and then storing new copies of it in the database in exactly the same way. When playing around with secret-tool, I noticed this bug. I suspect (hope) that my problems have something to do with it.

Debug Info

KeePassXC - Version 2.5.0
Revision: 1ab8a9f

Qt 5.13.1
Debugging mode is disabled.

Operating system: Arch Linux
CPU architecture: x86_64
Kernel: linux 5.3.7-arch1-2-ARCH

Enabled extensions:

  • Auto-Type
  • Browser Integration
  • SSH Agent
  • KeeShare (signed and unsigned sharing)
  • YubiKey

Cryptographic libraries:
libgcrypt 1.8.5

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions