-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Crash when using the secret service on a secret with a matching entry in the recycle bin #7933
Comments
KeePassXC seems to crash if a matching item is in the Recycle Bin. Steps to reproduce:
|
I confirm that there were a matching item in the recycle bin. There is no more crash since I cleared my recycle bin. |
The code already tries to exclude entries from the recycle bin, but it looks like some edge cases slipped through. What are the layout of entries in the recycle bin? Are they directly belong to the recycle bin group, or are there additional subgroups involved? From a quick glance of the code, it may be the case that entries are only checked for whether their direct parent is the recycle bin. @JGoutin, I'd love a backtrace when the crash happens (i.e. type Note to myself: this might also be the cause of #7850, check if that is the case. |
They are directly in the Recycle Bin. They don't have to be that complex, it seems an attribute is enough to lead to the crash: edit: |
The entry class has a |
There are no subgroups in my case.
|
Thanks for the backtrace. This is indeed #7850. I'll prepare a new PR to fix this. |
Is it the case that both of you configured to expose the root group of the database? @maximilianovermeyer @JGoutin I'm wondering why entries in the recycle bin are returned by the entry searcher in the first place... |
For me, yes. It's the default database created by KeePassXC if you haven't got any exposed groups and there is a save request via Secret Service. There is just: |
I see. That explains it. The entry searcher got confused when the recycle bin is also part of the exposed group. |
I confirm that the root group is exposed in my case too. |
Overview
KeepassXC crashes when using the "Secret Service Integration" in some conditions.
The crash occurs when I try to access a specific secret from Pycharm (But not all secrets, even with Pycharm).
EDIT: In fact, this is because there is a similar entry in the recycle bin (See: #7933 (comment)).
Steps to Reproduce
Expected Behavior
KeepassXC does not crash.
Actual Behavior
KeepassXC crash immediately when accessing the secret.
Context
The issue is with the version 2.7.1, but was not in the 2.6.6 version.
KeepassXC was installed using the OS provided package.
If I reinstall the 2.6.6 version, the crash does not occur.
The secret that always generates the crash look like (DOMAIN and PASSWORD are replaced values):
IntelliJ Platform Git HTTP — http://DOMAIN@dev.azure.com
http://DOMAIN\@dev.azure.com@PASSWORD
http://DOMAIN@dev.azure.com
IntelliJ Platform Git HTTP — http://DOMAIN@dev.azure.com
com.intellij.credentialStore.Credential
This other secret is also used from Pycharm in an equivalent context, but always works as intended (UUID and PASSWORD are replaced values, UUID is a common UUID in standard format):
IntelliJ Platform GitHub — UUID
UUID@PASSWORD
UUID
IntelliJ Platform GitHub — UUID
com.intellij.credentialStore.Credential
I get the following debug info (I only put logs that were generated after I triggered the access to the secret):
gdb
strace
KeePassXC - Version 2.7.1
Revision: 5916a8f
Qt 5.15.2
Debugging mode is disabled.
Operating system: Fedora Linux 35 (Cloud Edition)
CPU architecture: x86_64
Kernel: linux 5.16.20-200.fc35.x86_64
Enabled extensions:
Cryptographic libraries:
Operating System: Linux (Fedora 35)
Desktop Env: KDE
Windowing System: X11
The text was updated successfully, but these errors were encountered: