-
Notifications
You must be signed in to change notification settings - Fork 155
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
SecretServiceDBusHelper.Get() try to access locked secrets #355
Comments
I am having this issue with kwallet secret service too. Which basically means you need to sign in manually every time you start PC. |
Hey @histausse can you please provide your KeepassXC version so we can verify this behavior. |
I'm using the one available in the archlinux repository: |
Hey @histausse I used the AppImage version of KeePassXC 2.7.4 on Kubuntu 22.04, which also doesn't have a default secret service setup. I am able to get KeepPassXC to prompt me for a password without any changes. But it seems that it does not send a signal that the prompt has been closed.
If I use the version available via the Kubuntu repos (2.6.6) I get the following output:
Is this similar to what you see? |
Not really, but it's simmilar, probably because the secret are already stored on keepasswc. On my hand I have this error:
Keepassxc prompt for unlocking access On my patched version, after the message
the bridge ask to unlock the secret I'll try to see if I can reproduce on a clean VM when I'll have some time. |
I have managed to reproduce the issue. I didn't have the db setup to allow access through the secret service. |
This issue may also be affecting #359 |
Closing this issue as it is a duplicate of #359 @histausse The fix for #359 will also solve the issue you are having with KeepassXC. Everything works as expected on v2.7.4 now. |
I am using keepassxc as a password manager but the bridge fails to access its secret using secret service.
After investigation it appears that
SecretServiceDBusHelper.Get()
try to access the secret without unlocking thems first.Expected Behavior
The bridge should be able to acces its secret stored by keepassxc by unlocking them first.
Current Behavior
The bridge does not unlock all its secrets, resulting in an error when trying to access them and ultimatly leading to a "Vault is insecure" error message:
Possible Solution
One way to solve this is to explicitly unlocking the items before quering them:
Steps to Reproduce
Running the bridge with keepassxc's secret service integration with the option "confirm when password are retrieved by clients"
I already had the bridge more or less working with keepassxc before it stopped working completly with the last update, so some other steps may be required to repoduce.
Version Information
The example and potential fix are for the version v3.0.19 of the bridge (commit c6f1f15)
The text was updated successfully, but these errors were encountered: