We do this now also for gpg-wks-server. Further gpg-wks-client now sends the current language to the server so that the server can get back to the user with a proper translated text (if configured).

Alright. We use utf-8 in our template files and switch to QP encoding when needed.

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.

Tools / Refresh OpenPGP certificates runs gpg --refresh-keys. I don't think that this command knows anything about WKD.

Done by T7649: gnupg: Use KEM interface for encryption/decryption

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.

Fixed in most cases.
Edge cases will be examined further.

In T5993#201111, @werner wrote:

For example Poppler uses GnuPG comment packets to lower its own attack surface by leaving all OpenPGP handling to gpg. The patch (or at least the version we noticed in Fedora and Debian) entirely breaks this use.

(The commits had a wrong bug it in their message)

It might be useful to have samples of compressed keys:

No, we can't do much about this. It has always been easy to create compression bombs and the more relevant thing here is compressed signed or encrypted data. Or just compressed mails. The patch by @DemiMarie is way to complicated for what it wants to achieve and actually breaks existing use cases. For example Poppler uses GnuPG comment packets to lower its own attack surface by leaving all OpenPGP handling to gpg. The patch (or at least the version we noticed in Fedora and Debian) entirely breaks this use.

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

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.

Meanwhile we have some support for an empty subject but gpgsm still prints an error notice. See the T7171 for more.

Included in 1.11.1.

In T3362#177192, @werner wrote:

Well, see my very first comment.

• We should make card-timeout work again
• For OpenPGP cards we could extend our magic login data (scd/app-openpgp:parse_login_data) to introduce the timeout @gniibe suggested.

engl. Menu Entry: Save Secret Team Key
Tooltip: Save this secret key to share with other team members.

Discussion and background for naming things and german translation

For the icon:

We decided to

A brief update: This feature has not made it onto the roadmap of specific things to implement so far.

There was another customer wish for this, RT #34722

BTW, fingerprints for X.509 are not well defined because you get a different one when changing the *unsigned" attributes. Not a common case but one should be aware of it.

regarding the 403: one has to try the correct page AFAIK. Didn't research which one, look in the update checker code.

In any case, the actual connectivity test needs to be performed by GnuPG. Otherwise we might just test whether the Qt/KDE libraries can reach versions.gnupg.org, but not whether dirmngr can. Werner proposed something like gpg --fetch-key https://gnupg.org/index.html.

this is not yet in master and not included in the current testbulid

We have done all of this and the rest of the work is now in T7593

Hey there. I wanted to bring this up again, to see if we can perhaps get this changed after all:

BTW, do we really need a C++ API for this? Might make sense due to the need for a context.

Well I finally did some more tracing and removeOurAttachments_o is not called when the attachments vanish.

5.0Beta:145: OK and works, both for signing and encryption

Please grey out the "Anyone …" sentence, too.

The option is available now and it works:

If RestorePositionForNextInstance=false is still there after gpgpass has been quit then either KMainWindow::closeEvent() didn't run or the dirty state config wasn't sync'd to disk. When reading the code in KMainWindow I was wondering if a sync() was missing, but in Kleopatra it worked without this.

Version 4.0.0.250370 (Gpg4win-5.0.0-beta125):

After testing the feature again with Beta 5.0.0-125 I repeat myself: this works.
There is the action "Unblock card" for unblocking the card with the rest code / PUK.

New API gpgme_op_random_bytes is now in master (gpgme 2.0). Use tests/run-genrandom --help for testing. Extra features will come soon.

VSD 3.3.0: OK.

ok in VSD 3.3.0, too

Removed in https://invent.kde.org/pim/kleopatra/-/merge_requests/369

We do support "Decrypt & Verify" for multiple files (including the presentation of the status) so that it would be easy to do the same for all files in a folder (question is if this should even be recursive). Digging into the history I found that the desktop file was added shortly before Kleopatra 2.0.0-rc1, but that there wasn't any code for iterating a folder, i.e. this can never have worked.

As I am delving a bit into cryptocurrencies and since i have a ledger security token and a bip32 24 word mnemonic now backed up as stamped metal i have stumbled accross this topic:

I'm glad that inotify is already in use, that's a reasonable thing on the Linux platform.

This is the old code from gnupg-2.0/agent/gpg-agent.c:

inotify is already used used on Linux to check for a lost homedir. The once-in-a-minute check should be the same as with the other daemons and has proved to be very useful. The whole thing has been discussed over and over again a long time ago and - as with other system daemon - we agreed on scheduling at the full second.

I think there's some confusion.

changed the workboard to gpd5x as this is still the case in Gpg4win 5.0-Beta versions.