Hint from @gniibe: gpg --with-colons --list-config curve is a workaround.
So it still should be documented and made accessible from a non-esoteric, non-internal way. ;)

Did that help any?

You can close the report.
I'm working with a restricted user and I installed gpg4win-3.1.0 with admin rights, probably didn't work so well.

See also Filippo Valsorda's 32c3 talk about CSPRNGs.

@gouttegd : setting only-urandom at the distro level problematic due to two factors:

You are welcome :-) I did not know about that 39-Arigato

I've been working with one of Microsoft's developers on a temporary tool that should bridge the connection between named pipes and the Unix sockets emulation used by gpg-agent but things appear to trip up with sending the nonce. From the position of the tool, the nonce value is successfully sent (send returns 16), but never seems to be picked up by gpg-agent. Instead both gpg-agent and the bridge sit there until whatever tool is using them (I test using ssh-add -l) is terminated, at which point gpg-agent immediately spits up the message

@dkg : Can’t this be solved at the distribution level? I assume the packager/maintainer for Libgcrypt on a given distribution should know whether the getrandom syscall is available on said distribution, so he could install a /etc/gcrypt/random.conf file with the only-urandom option.

Werner wrote:

we already use the getrandom system call if it is available

Neither Brainpool nor NIST curves make any sense unless there is an organizational policy requirement. Thus the --expert requirement is the Right Thing (tm).

3.1.0 is released and this issue is to our knowledge fixed.

( Apart from the part that was moved out to T3895 )

3.1.0 is released and this issue is to our knowledge fixed.

3.1.0 is released and this issue is to our knowledge fixed.

3.1.0 is released and this issue is to our knowledge fixed.

3.1.0 is released and this issue is to our knowledge fixed.

3.1.0 is released and this issue is to our knowledge fixed.

3.1.0 is released and this issue is to our knowledge fixed.

3.1.0 is released and this issue is to our knowledge fixed.

3.1.0 is released and this issue is to our knowledge fixed.

3.1.0 is released and this issue is to our knowledge fixed.

3.1.0 is released.

Thanks again. Good catch.
In Japanese 39 sounds like "Thank You!", that's indeed appropriate to your report. :-)

Werner it would be great if you could look into this. This is currently my most annoying 2.1. regression. Especially with auto-key-locate it is unintuitive when the Firewall question pops up and appears to come out of nowhere (e.g. adding recipients in GpgOL or in Kleopatra).

I think you are running in the infamous T3459 "As long as the decrypted content of a crypto mail is loaded a mail can't be moved" You have to unselect the mail and then move it without opening it. E.g. by right clicking it. I know this is horrible and it's a major problem but I don't see how we can fix it in our architecture. As we replace the mail content with the decrypted stuff we have to prevent "Write" Events by Outlook. For Move if you block a write event, the move fails. But we don't have any idea in our addon when a write comes from a move. I spent a lot of time on this and have not yet found a good solution. But I think the workaround is kinda ok.

The Bug is here that the Error is not shown properly. In the log:

I changed the title to express the problem.

Thanks for the script.
I confirmed that secring.gpg is not updated when importing key with updated expiration date, by GPG1.
So, for GPG2, it is expired key.

When a command is invoked from Midnight Commander, pseudo tty is used.
You can confirm that by typing tty and see the output of the command after exiting from mc and again typing tty.

I am currently considering improvement of finalizer of libgcrypt, so, this matters.
Looking code, it would be better not to allocate and free the constant,
but use compile time constant data in .text section; Something like: const unsigned char ctr_null[DBRG_CTR_NULL_LEN].

Applied to STABLE-BRANCH-1-4, too.

Good catch. Thanks. Fixed in STABLE-BRANCH-2-2.

Apparently, your /lib/x86_64-linux-gnu/libgpg-error.so.0 is not the one you installed (I mean, libgpg-error version 1.27).
You need to install your new version of libgpg-error so that it is usable.
Please check your ldconfig or LD_LIBRARY_PATH, etc.