My experience is that using a string is much easier and less error prone that to build up and allocate an error obj objects. A string leads to less code and bugs are easier to detect. There are enough patter on to handle strings in a safe way and key specs are in most cases already available in string form (e.g. hex fingerprints), be it from a mail interface, as a result of a database query or from the command line.

Is that on Windows?

The use of --textmode is in general not a good idea. The GPA on Windows will work just fine regardless of line endings. Notepad.exe also does not care about line endings as does other proper text handling software. If there is a problem c+p from the GPA "clipboard" do the system clipboard we can fix that.

Just checked. This does not seem to be a regression.

Hey, you want to get this into 1.11.1 I assume - Let's consider this a bug fix and not another API change.

Weel, you GnUPG version is actualluy the lates. Unfortunately I tested with a beta version. Let's wait a day to see whether there is more fallout and if not I will do a 1.11.1

Look like you are using an older GnuPG version and thus the test fails. I need to tweak the test.

Are you asking for a way to --refresh-keys via GPGME? IF so shall that be a syncronous thing or just a trigger. Note that we the last update time is already part of gpgme_key_t and can thus be used to check whether a trigger worked.
Anyway this will be a larger change and may need gpg support.

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.

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.

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.

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