I'd sad we keep it as it is now (unless we see a regression). The real and only correct solution is the use of a daemon to serialize access.

That might be related to T2196 which has been hopefully fixed in 2.2.50 and also in the next 2.6. Closing this task.

That might be related to T2196 which has been hopefully fixed in 2.2.50 and also in the next 2.6. Closing this task.

I applied it to the 2.4 branch but please do not continue to translate for 2.4. 2.6 (master) is the new target.

Implemented but not tested at all.

At which point did were you asked for the passphrase for decryption? You flushed the gpg-agent cache, right?

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