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:

This one made me curious because updating the should be UI solved, and it is incredibly dangerous to mess with that. It is super easy to get random crashes when you invalidate the UI too much. It took me ages to get that "stable enough". But also technically an appointment request is a mail. And thanks to dan (afair), KMail can sign and encrypt invitations. And at least for signed invitations they are displayed as appointment so I looked into this a bit out of curiousity.

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?

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.

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

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

In T7658#201260, @TobiasFella wrote:

That screenshot is for kleopatra crashing, not related to okular.

Outlook problem that can't be fixed.
Workaround possible (First start message, then add recipients).

That screenshot is for kleopatra crashing, not related to okular.

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:

For illustration:

The problem here is that the version number in kleopatra is still 4.0.0-something, which is then compared to 4.4.0.

Checked with Gpg4win-4.4.1-beta59, too, which contains gpgme 1.24.3. Works!

Apparently KMessageBoxes do actually wrap, just at a larger width than we'd have expected. Lowering this width should be a trivial patch that we could do locally, if we want to

Hej thinks that she would expect the dialog to show which certificates were uploaded.
I think if we want to do that, we should make a new ticket for it. Here we wanted the easy quick fix.

"Geheimen Team-Schlüssel zum internen Teilen abspeichern." is grammatically correct, but it sound very formal and clunky for a UI tooltip. It lacks clarity, therefore I suggest:

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.

Tooltip: Save this secret key to share with other team members.
dt. Menüeintrag: Geheimen Team-Schlüssel speichern
Tooltip: Geheimen Schlüssel speichern und mit Team teilen.

Werner strongly prefers to include it in the self-tests instead of adding a command to the drop-down list.
I will therefore update the description accordingly.

basically solved, for follow up see

• T7652: Kleopatra: Add plural in verification messages for multiple signatures
• T7651: Draft: Kleopatra: Improve color codes of verification result messages

"Upload successful." or "Upload complete." (even shorter) for the title bar are fine :)

I forgot the differentiation between singular and plural…
Maybe "Upload successful" would be enough.