With the recpstring feature in 1.11 this is now possible because the args are passed verbatim to gpg.

With this example, the problem happens at
a->size |= iobuf_get (chain) << 8;
iobuf_get (chain)returns -1 and -1 << 8 is not well defined.

Sorry, I can replicate this with current 2.2 nor with master (on amd64 Linux):

Implemented in gpgme 1.11.0 if gpg >= 2.1.23 is used.

We never tried to build gpgme with MSYS2 and I would also say this is not supported. A wild guess is that this mixes platform specific code.

To attach a file use the cloud-with-arrow icon in the edit toolbox.

1.11 features a set of extended encryption functions which may optionally take a string as key specifications. In contrast to the array of key objects this string is a linefeed delimited list of key specifications which are passed verbatim to gpg. For OpenPGP a keyword feature is supported. For example the string

Just tested 1.1.0 - no difference. BTW, check references issues, they contain strace output and mention why this happens: dropped root capabilities to ignore file permissions.

Thanks @werner for applying the patch. Closing here, since I have been using that patch for several weeks now without ever encountering the bug again.

A reason we did not touch it in the past is that Ideally we don't want users to have to mess with refresh keys but would rather have this done automatically in the background by dirmngr.

I wonder if CACert intentionally sabotages X509 / CMS.

Would you be able to test with pinentry 1.1.0 which has a few things to make debugging easier and is also what I am testing against. To check what permissions are wronf I would suggest to run under strace.

Got the question about this note from a user (in a internal email) and I see the problem that users do not have enough information to decide this. They do not know what the consequences of this note are (and suspect it to be the cause of error of they see it together with other problems). So to me it is more than a 'wish' as it will generate questions and leaves users in a situation where they cannot progress by their own in most of the situations.

It is not an error or even a warning but just a NOTE. Thus the user should decide. it is not even translated and most systems this is enabled anyway.

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.