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?

The current links should be replaced or removed.

You could verify this with another email address containing a +.

How can I check this, @ikloecker ?

Can you check whether the + character in the email addresses is causing this?

Because I'm just starting with GpgOL: Are we talking about adding links in the "Configure GpgOL" window or are there any other windows? If that is the right window maybe we could add a new tab "FAQ" and add the links there. At first I thought the links could be added to the tab "GpgOL" but there are already many entries and the other tabs don't fit well.

I can't replicate this symptom (gpg1 generated key, no problem after migration).
Could you share the *.key file under private-keys-v1.d?

I think that this commit rG8fd150b05b74: gpg: Remove all support for v3 keys and always create v4-signatures. matters.