Thanks for looking into this issue :-)

You may want to check with Hanno Böck

Ben: We need to use a faked system time thing to make those tests more stable.

I backported the fix for 1.8.3.

The semantics of --list-only are not well defined. Needs some overhaul.

Cherry-picked this for 1.8.3.

FIPS rules changed anyway and thus more rework will be needed anyway. I keep this open at low priorirty.

This is a build system setup problem with standard solutions.

An option to ignore SRV records would also be good for debugging. Thus I raised the priority and truned this into a feature request.

@Beiri22: It was my fault to to tell you to use scdaemon.conf. The correct conf file is of course dirmngr.conf. However, with @BenM comments I don't think that it is a bug at all. I am thus closing this; please feel free to re-open if we were wrong

Then please set DISPLAY ;-)

Do you have a chance to try with a more recent pinentry; ie. 1.10 ? This may give better diagnostics.
Another thing I would suggest is to debug the invocation of pinentry: Put

Thanks for the description and the patch. I know what fuzzing is and GnuPG underwent quite some public and non-public fuzzing already. You may want to check with Hanno Böck to see how fuzzing can be done with gpg.

Sorry myself.
I will try to be clearer :

Ok, thanks for the reply

Thank you :)

Thanks. I only now noticed that this is the same as we already use for 32 bit MIPS. I have no more questions. Will push to master and the 1.8 branch.

That is all intended. You can always create broken messages which don't result in _one_ clear error code.

Clang doesn't support the "h" inline asm constraint and the C version of umul_ppmm() works on MIPS64.

Sorry, I do not understand your request. Please describe what you want; linking to some arbitrary external sites is not sufficient.

Your patch indicates that all clang versions for MIPS64 support this feature. Is my reading correct?

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.