- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Thu, Jun 12
Wed, Jun 11
Parts of the changes made for T7183: Kleopatra: Reduce certificates offered in Sign/Enyrypt dialog have been reverted. The drop downs for selecting the signing key and the "encrypt to self" key now offer the primary user IDs of usable keys again (instead of all user IDs of usable keys) and there's no button to open a certificate selection dialog anymore.
I started Process Monitor only after Kleopatra hang so that I cannot find out which process started gpg-connect-agent.
Log files for above deadlock
I just had another hang.
Jun 5 2025
In Kleopatra we explicitly trigger a re-reading of the smart card after each operation involving a smart card to ensure that Kleopatra doesn't show wrong information. There's so much that can go wrong with physical smart cards that this is the only way to make sure you don't tell the user lies. I think gpg --edit-card also re-reads the smart card after each operation.
There is no bug in the contexts and there's nothing to document anywhere. If anything then it's a bug in gpg's generate command or a more general issue (in gpg-agent) with keeping track of the storage location of private keys as I have already explained in T7620#200613. I'm removing the gpgme tag because there's nothing wrong in gpgme and there's nothing we can do in gpgme. It needs to be addressed in gnupg.
Let's have a look at the section of RFC4880 linked by the reporter:
A User ID packet consists of UTF-8 text that is intended to represent the name and email address of the key holder. By convention, it includes an RFC 2822 [RFC2822] mail name-addr, but there are no restrictions on its content. [...]
Jun 4 2025
Jun 3 2025
Jun 2 2025
May 30 2025
Yes, for GPD and VSD there probably should be version numbers in swdb.lst if the update check should actually be active in those distributions. I think for VSD the update check is usually deactivated because a) it accesses the public internet which some customers don't want and b) the software is usually not installed by the users themselves so that the update check doesn't make much sense.
Tagging with Windows because the update check is a NOP except on Windows.
In T7656#201529, @ikloecker wrote:In T7656#201519, @TobiasFella wrote:Do I understand correctly that this bug is then automatically done/fixed?
It depends on how the version comparison works. We may have to change the code to extract the version number (e.g. 5.0.0) from the version string.
By the way, Kleopatra uses GpgME::SwdbResult::query() which I expect to do what you propose.
First, gpgconf doesn't help with parsing a version string like gpg4win-5.0.0-beta190 which is what I was talking about. Once we have extracted "gpg4win" and "5.0.0" we could use gpgconf. ...if it worked as documented in the man page. I don't understand this:
$ gpgconf --query-swdb gpg4win 4.3.0 gpg4win:4.3.0:-::32849:::::::
May 28 2025
In T7656#201519, @TobiasFella wrote:Do I understand correctly that this bug is then automatically done/fixed?
Is this what you had in mind @werner:
May 27 2025
Note: The Kleopatra in upcoming versions of Gpg4win 5 will have AboutData::version set to gpg4win-5.0.0 (or gpg4win-5.0.0-beta190 for beta versions). See T7666: Kleopatra: Rework versioning.
Tools / Refresh OpenPGP certificates runs gpg --refresh-keys. I don't think that this command knows anything about WKD.
May 26 2025
Fixed. Thanks for the report!
May 20 2025
The changes have only been implemented for the upcoming Qt 6 based Kleopatra, i.e. Gpg4win 5. I have updated the project tags accordingly.
May 19 2025
May 15 2025
It's pretty much impossible to speed up the situation of unavailable network because network access typically uses long timeouts because networks can be notoriously slow to respond. The only thing we can do is show a progress window so that the users know that Kleopatra is actually doing something.