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.

So, what shall we do with vanilla kleopatra, or GPD or VSD? It will be easy to record current versions number in swdb.lst

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.

I forgot to mention that gpgrt has an API to compare version numbers in the same way gpgconf and all gnupg components do it; this should be somewhat similar to sort -V

BTW, if you append a beta string the thing works as well. Thus with an development version for 4.4.2 we would get a 'newer' state:

The version file is locally cached and updated from time to time unless that feature is disabled.
An update can be forced using

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:::::::

This is all done by gpgconf like here:

To clarify. And what I think might still not work here. Windows has the problem that it does not remove the temp directory on restart or even attempts to. So whenever we work with temporary files we need to make an effort to remove them. Because the user does not expect a decrypted file in a temporary folder to stick around forever. There are options to do that on Windows. As a last resort one could even create a registry key like we did in the uninstaller for a while to remove files which were in used after next reboot.

Actually after looking at this post here I commented on https://dev.gnupg.org/T7434#201525 Since you are already debugging and seem to be able to reproduce this somewhat more often then others. (I hope even aftger all this time? :) ) Could you try running porcmon with the generic gnupg path filter as suggested there. Will slow everything down of course, but I would love to get my fingers of such a hang like you are seeing with such a filter enabled. You can export only the filtered lines and compress it. If it is still too large or private I guess we can get you an upload space somewhere. But some unexpected situation caused by a third party software messing at the right time with our files would really fit the bill, and I already noticed that standard windows defender, in a standard windows installation messes with our lock files. Maybe you have some even more agressive software running and see such issue more often, the important thing in the procmon log would be what kind of error / access pattern occurs to figure out if we handle something not correctly, or interpret it differently.

Just as a reminder, knowledge transfer, because this is easily overlooked in testing but at least one customer would have gotten very annoyed if we had ever deployed an "Update all certificates" function which "added" new certificates. Even with the update of a single cert, we had a "funny" issue, like if you had expired certificates from anywhere and not from WKD (which old keyrings have a lot, maybe with many uids). Suddenly an update would pull in new keys which come from WKD but maybe there they all only have one UID. Because for keyservers the identifier was the fingerprint and for WKD the identifier was the userid.
Or even worse, you explicitly threw out the OpenPGP keys from WKD because you wanted to use only S/MIME, then such a function may not search on any OpenPGP Sources.
When I worked at Kleopatra we didn't want such a feature in GnuPG. Our strategy was to update keys when they are used, about to be used or close to expiry. The whole locate-external-key thing.
I think the feature we had to update in the certificate details is good. But i recommend especially keeping the S/MIME / OpenPGP difference in mind. I would also call it "Search updated certificates" with a tooltip that it might also find "new" certificates for the user. And then an option to disable this either for S/MIME or for OpenPGP.

In T7656#201519, @TobiasFella wrote:

Do I understand correctly that this bug is then automatically done/fixed?

The more I think of this, the more likely this appears to me as the source for all that random startup weirdness of GnuPG. Say you are on a large keyring and on a train, then that keyring is first passed through your enterprise malware protection for scanning or something like that. Then it works again until some metric, hash or something else changes.

My recommendation would at this point be to use procmon with a file filter for just "If path contains gnupg then include" I mean maybe go only for the locking dirs but this way you will not only see what the GnuPG processes are doing but what everyone on the system is doing to the locks. So you will see when my old friends, third party security software might interfere.
For example: You will see on a default Windows which files are checked through telemetry. And here in this example you see directly that the Microsoft Malware Protection Engine is accessing the agents socket.

Yes. If gpgconf could read that version directly from kleopatra it would be even better. Bit in cases of early crashes this might be sub-optimal; thus I will tell gpgconf to get some additional version info from an installed versioninfo.txt file (which gpg4win creates). Thanks.

Is this what you had in mind @werner:

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.

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.

For vsd on Windows this will be solved due to the use of gnupg-vsd as default homedir. We already tested this with a beta MSI installer

This should compare the gpg4win version number:

In light of the ticket T7630 this one is obsolete

We decided to

• remove the "Cancel" Button in case only one secret key is imported (as this does the same as "No")
• in case of importing more than one secret key we want to change the text from "Cancel" to "No for all".

When you've implemented the link solution here, do the same for T5006

Please solve this the same as our solution in T7630: add a button in the results window to open a new window with all the imported certificates.

Possibilities for the button text:
"Show import window"
"Show import tab" (I know it is no tab but its shorter)

The changes have only been implemented for the upcoming Qt 6 based Kleopatra, i.e. Gpg4win 5. I have updated the project tags accordingly.

After completion of T7553, the result for one file looks like this: