Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding the ability to unlock the database requiring yubikey using KeepassXC param and DBUS #9229

Open
piorkov opened this issue Mar 12, 2023 · 3 comments

Comments

@piorkov
Copy link

piorkov commented Mar 12, 2023

Summary

I really miss the ability to unlock the database in the GUI in case yubikey is used for encryption. Similar functionality is already added to CLI, but it is missing for GUI and DBUS.

It would be useful to add an analogous yubikey parameter as this added to CLI, as well as a method in DBUS which also handles yubikey

Examples

Add param: --yubikey <slot[:serial]> YubiKey slot and optional serial used to access the database (e.g., 1:7370001).
Example:
keepassxc <db> --pw-stdin --yubikey 1:7370001
Add dbus method:

    <method name="openDatabaseYubiKey">
      <arg name="fileName" type="s" direction="in"/>
      <arg name="pw" type="s" direction="in"/>
      <arg name="yubiKeySlot" type="s" direction="in"/>
    </method>

Context

I would like to use an external tool to unlock the database in the GUI, but as my database uses yubikey I can't do it in a simple way (Yes I know that the program remembers the yubikey used previously, but for me it is not enough)

@piorkov
Copy link
Author

piorkov commented Mar 18, 2023

Pull request #9251

@aitorpazos
Copy link

Hey team, another user here who would love to have this feature available. I see #9251 conversation revolves around a refactoring needed, but from a user perspective I would love to see this feature being available.

It is blocking me from being able to startup keepassxc on login and make it my default secrets service provider as there are a bunch of apps that would try to read from that service on startup and having them failing to do so on startup (as it may take a while for me to open the GUI and unlock the DB) results on a bunch of credential request dialogs and failure messages from those apps.

@droidmonkey
Copy link
Member

droidmonkey commented May 18, 2024

In all technicality, you should be writing bugs against those software items that don't behave correctly in the absence of an unlocked password store. They should wait patiently for the store to be unlocked and/or offer the user an easy way to retrigger authentication after unlock is done. That is how the secret service specification is written.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants