We recently noticed problem at a customer site with creating the standard rsa3072 keys. It basically stopped working. A likely cause for this seems to be some anti-malware software slowing down file system calls. In the wake of this we looked again at our file locking strategy and found a few things which are not as they should be. For example the release of the lock before a Close call. Trying to fix this unfortunately caused other problems, thus a couple of fixes are needed.

(auto resolved due to the keyword "resolved" in the commit message)

That is on purpose. With a signed mail you have at least a way to tell who sent the mail. An unsigned but encrypted mail can be send by anyone and you netter don't use HTML links there.

I implemented that in the old 2.2 branch for easier testing.

Please let us not clutter the code with OS specific things. We could use a gnupg_remove_ext or gnupg_remove_maybe_wait with a wait parameter which maps to a plain gnupg_remove for Unix. The GPGRT_PROCESS_DETACHED, in the asshelp is also the only specific thing which can be move to a file global macro.

The gnupg_remove should retry if it has a sharing violation. Similar to what we do in gnupg_rename_file. I just figured that we do a remove in the latter function too w/o handling a sharing violation.

That is a real interesting description for the commit :-(

Obviously this is the updated to 2.2.49

ECC support for X.509 and in particular pkcs#12 format is limited. That is in general not a problem because such certificates are stored on a token and not on disk.

Also implemented for 2.2

Will be backported after 2.2.49

FWIW: The fix rO75f46829054e is part of GpgOL since 2.6.3

2.2 test can be done with GnuPG-VS-Desktop-3.3.90.12-Beta-Standard.msi from Sep 17

Interesting. That means to replace hundreds of scripts in an average organization :-(.

Backported to 2.2 but not yes tested with 2.2