Can't you just use file descriptors everywhere and use _get_osfhandle. That is what I am used to seeing in Windows code in Gnulib (although I do not touch it much).

Regarding 64bit handles https://learn.microsoft.com/en-us/windows/win32/winprog64/interprocess-communication
tells us:

This seems to be a good opportunity to replace paperkey with a new tool to take advantage of the smaller ECC keys which allow us to re-generate most stuff.

Ingo tested this and it worked.

But we have the same problems on Unix as described by T7699. (funny, the other bug mentioned above has 76 reversed)

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.

After several gpg4win-5 betas be can set this task to resolved.

I claim this resolved given several gpg4win-5 betas.

I claim this resolved given that we had several gpg4win-5 betas and no reported problems was related to this.

The actual project we had in mind for this was more or less canceled and thus I re-prioritize this task.

This was release with 2.5.7.

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: