The problem here is that iobuf_readbyte returns -1 on error and on EOF. parse_packet is not able to distinguish that because for histroic reasons we do not return a gpg-error code (GPG_ERR_EOF). To fix this we need to change all callers of parse_packet to not act upon -1 but only on an error code.

Except for the release/unlock thing after keybox_compress I already have the other fixes in my 2.2 commits. I noticed that the gpgsm keydb lock/release stuff differes from the one for gpg: For gpg we use the keybox_lock function but that is bot used at all by gpgsm. In theory this should be unified but I fear a regression risk and thus for 2.2 we better don't touch it.

Shall we merge this with T2196 ? BTW, I have some unpushed commit and a test installer.

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