Thank you. Applied.

Implemented.

Thank you for the error output.

it still shows the no certificate or invalid encoded error message:

And I move functions from pinentry.c to pinentry-curses.c, so that pinentry-w32.exe can be build with no libiconv (which is actually not used).

Thank you for your report.

Merged into T5804.

Thank you. Confirmed.

Thank you for the reproducible test case. Confirmed.

Pushed the change removing the definition.

GetNativeSystemInfo. Would you like me to submit a patch that used that in jent_ncpu?

Thank you. Confirmed.

Thank you.

Considering again, I think that just removing the definition of the struct timespec in npth.h is the best approach, given the situation, it's been there for MINGW64 and it's now in original MinGW.

Thank you. I understand the situation by looking at mingwrt-5.4.2-mingw32-src.tar.xz.

In libgcrypt (1.10), we have a copy of the jitterentropy 3.3.0 from:
http://www.chronox.de/jent.html
or https://github.com/smuellerDD/jitterentropy-library

I had thought that we need to combine hkdf so that key and iv can generate within libgcrypt internally.
Probably, this assumption of mine may be wrong.

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.)

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

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.

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

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.

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.

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.

And updated scd_validate2.py:

Wrote a pam module which interacts a user for auth:

Thank you for your comment.

I write a prototype in Python using pyassuan:

Sorry. While v5 things in the specification is still in flux, from the viewpoint of the implementation, this patch is 100% valid and it makes sense.

Fixed in master and 2.2 branch.

Thank you for the report.