This will never happen on stock Linux.

We decided to keep the color white for these cases and only add some further information, see T7701: Draft: Kleopatra: Add information for verification results

I know of no current Linux issue with this, I thought only the MSI installer is affected

That is not Windows specific. They should end up in %GNUPGHOME%/kleopatra/

What about including the output of

This is more a technical ticket. There's not really something to test. Setting to Resolved/Done as discussed with ebo.

Note that the first screenshot shows still "Sign/Encrypt" as button text instead of "Finish", but I didn't notice that again after this

Most issues with icons in high contrast modes (of Windows 10) should have been fixed. Needs to be verified especially with the high contrast modes of Windows 11.

Setting to Testing.

Moving to QA. All changes should be in the latest beta.

Many issues have been fixed. Setting to Testing to check what I have missed.

We decided in T7579: Kleopatra: improve menu items to remove this action. Users will instead have to mark certificates they want to update and use the Update Certificates action in the "Certificates" menu.

Can be tested with next VSD 3.3.x build.

Thanks! Maybe we should add a tooltip? "Default Appearance" does not have one and I do not find this self explanatory.

In T7212#201964, @ebo wrote:

Why are there 2 buttons for (probably) the same thing: "Default Appearance" and "Defaults"?

I have added the changes/patches to the vsd-3.3-branch of gpg4win

The relevant changes have been merged to the gpg4win branches of kleopatra and libkleo. We can start creating a test build

in 5.0-Beta-190

its not cleared any more in 5.0 Beta-190

If Kleopatra is already running then running

• kleopatra --help shows the help in a window
• kleopatra --help-all shows an error
• kleopatra --version, kleopatra --author, and kleopatra --license open the About window

Meanwhile we added a link to the GnuPG command line documentation at https://gnupg.org/documentation/manuals/gnupg/ below "More documentation" even in Gpg4win.

No, I have no admin rights on that computer: I installed the portable version, too. I saw that the previous version had been uninstalled before installation.
On a different computer I tried to reproduce the situation where GPG4WIN had been installed the standard way. I did not see the effect there. However when upgrading I got a message that the c library could not be written; that was because some Kleopatra windows was still open. After manually closing that, a retry was successful. Other software installers close the application before trying an uninstall or update, however.

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.

Just to be clear: You originally installed it as a portable applications and then you also installed a new version in the standard way?

I started Process Monitor only after Kleopatra hang so that I cannot find out which process started gpg-connect-agent.

Can you figure out who started gpg-connect-agent? Note that it is also used by gpgconf to reload, kill, or launch daemons.

And mind that the wording "This certificate is revoked" is wrong in any case, only the user ID is revoked, not the public key.

Log files for above deadlock

I just had another hang.

I updated the version database. We now have entries for "gpg4win", "gpd", and "vsd"

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.