- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Aug 26 2025
Aug 25 2025
I don't see the problem. The pattern "Kyber768" is ambiguous because it matches the user IDs of both keys. The match is a simple substring match. There's no logic for "exact match" and no heuristic for "better match". If you want to ensure that a specific key is chosen then you must use a unique identifier for the key. Best use the fingerprint.
Thanks for reporting/requesting.
Aug 24 2025
Aug 23 2025
Aug 22 2025
Aug 21 2025
Backported for VSD 3.4
Backported for VSD 3.4
Backported for VSD 3.4
Backported for VSD 3.4
Backported for VSD 3.4
Backported for VSD 3.4
Backported for VSD 3.4
Backported for VSD 3.4
I see from your other report that you are running a proper libgcrypt. But I think I spotted the bug: ECC+Kyber should not be displayed when adding a key. It is used for creating a new key ECC as primary and Kyber as subkey.
Nope: There are many different error codes returned, Kleopatra may want to map them to a common one.
Can you please try with gpg4win-5 beta: https://www.gpg4win.org/version5.html this makes it easier for us to see the reason. Deinstall gpg4win first and note that version5 is 64 bit and installed under Program Files (w/o (x86)). If it still does not work please add
Ooops. we already got a ticket for this.
Well, I will re-use this as a feature request to add this feature. Workaround is to list the key with --with-keygrip and backup the ~/.gnupg/private-keys-v1.d/<keygrip>.key files.
Please run gpgconf -V to which tells also the Libgcrypt version and more.
In the meantime pinentry has been updated also for VSD 3.4.
Backported for VSD 3.4