Thank you. Confirmed and applied.

Thank you for your report.

Please specify your MinGW version.

Please specify the version of MinGW, which you are using. (We use Mingw-w64 for GnuPG Project.)

Using an armor header would allow for this. But well, this blows up the data and frankly, I fear that it can lead to unexpected side effects. Better to use a respective file name or MIME header.

Actually this is pretty obvious; we better ignore such misbehaving servers.

Adding

GPG_TTY=$(tty)
export GPG_TTY

makes this working so thank you for the pointer.

No need for callbacks actually. We can do it in a simpler way. See commit rGe5ef5e3b914d5c8f0b841b078b164500ea157804

Now, the problem is not about the case of pid == getpid () any more.

That would be bad for unattended use cases. Recording the time the lock file was created might be a solution. Then cleanup only after 15 minutes or so.

Note that there is a race condition still (after a fix of one race condition which may be somewhat likely and reproducible, and another fix of race condition when there is a stale lockfile).

Fixed another race in commit: rG2f1afc129662: common: Fix another race condition, and address the other one.

{F3381469}I uploaded the whole homedir containing the keys after they were migrated by the new gnupg2.3.4. It should have all of the keys in there. Don't worry, these keys are just for testing and not used anywhere.

Is your GPG_TTY set so that pinentry can find the right tty?

Sorry, without detailed output of gpg we can't help you here. This is definitely not a GnuPG bug because too many people are using mutt and gnupg. You should also "set crypt_use_gpgme" -it works far better.

the -v does not show more useful info on the gpg side:

# gpg2 --quick-gen-key admin
About to create a key for:
    "admin"

Please run with option -v to see what's wrong with pinentry.

For the logic of detecting unlocking, it should work when h->use_o_excl == 1.

I had some more time to test this bug.

Before the fix above, https://bugs.debian.org/972525 can be explained by the following scenario:

Fixed in master. Should be backported when found stable.

I pushed a change for t-dotlock.c for testing.

There is a new key filter "Not certified certificates" that is selected if the button is pressed.

SWDB updated - thus the latest zlib will be part of the next Windows build.

we replace the encrypted text and attachments with the decrypted / verified parts

I can't replicate this symptom when I use gnupg1 for creating keys with no passphrase.

I think that the particular issue of Let's Encrypt Certificate was handled correctly already.

Yes, makes more sense to me, too. Maybe another filter "bad" certificates, so that you can bulk delete them for example to clean up your keyring?

@aheinecke What do you think?