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.

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.

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

Argh. I missed that. Probably because I searched for libgpg-error but I myself renamed the tag recently :-(.

To clarify: We already use the getrandom system call if it is available. To map /dev/random to /dev/urandom you can create a file /etc/gcrypt/random.conf with this line:

man dirmngr

--debug-wait 3

Please kill all existing dirmngr instances and don't run any programs which will trigger it to be started (e.g. Kleopatra). Then run in a _standard_ shell (cmd.exe):

Rhat's for the client, right. I never used it. We used to run a Windows 8 instance in a VM to run tests via ssh on it. That worked most not really stable. For obvious reasons I am more interested in the server part ;-)

Thanks. I took these patches and simplified them. Not test tested, though,.

It is in 2.2.6

That slipped my attention due to the missing gpg22 tag I should have added. Sorry.

Yes. However, I have tested a fix for the empty value.

I still can't reproduce the crash (on Vista).

Will be in 2.2.6.

Thanks for the pointer. But as long as the Windows ssh server is that instable I see no urgent need to add this to GnuPG.

Oh, you used a single dash and not a double dash in --armor. That is obviously the problem. As per Unix history all option characters may be combined unless they take an option arg; in that case the arg for the option may go directly after the option letter. We can't change that because lots of people and scripts use -rRECIPIENT.

To be released with 2.26 next week

Right with (2) (1) will not occur if the key has been created with GnuPG. However, we have caches in the code path and further rogue software may create creates, interesting keys (tm). Thus I consider it better to explicitly request keys with cert flag set.

Forget my former comment. We only need to check subkeys becuase the primary key can always certify.
Here is a new revision of the patch:

I have another patch proposal to check the key usage. However, there is a catch-22. We get the usage flags from the key signatures and thus we can only check them after we checked the key signature.

The gpg20 tag was a typo.

Hmmm, needs to be investigated.

For secmem.c this is on purpose. For the others we should fix that.

Okay. We need to add a FAILURE status so that gpgme can better report this invocation error. Due to the double fork it won't be able to see the exit status. I assume you have the same problem in Enigmail.

Thanks. Indeed this should also use the x... wrappers. It is not severe because this value is only used as a fixed constant.
Thus we won't fix it in 1.8 but should do this 1.9.

I also stumbled on this problem in the past. However, I did not changed it because I feared to break callers which expect that the passed key object is not changed on error. This may happen in a loop where you test for an ambiguous key and don't save zway the first retrieved key. In the error case (i.e. not ambiguous) this would dump the good key object.

You can do a

Under Wine it does not crash but returning an empty string is not a good idea in any case. The question is what to do with "c:". The usual meaning is to use the current directory of drive C. But that does not make much sense. Should we simply assume that "c:/" was meant?

I pushed two fixes. One which hopefully avoids the corrupted trustdbs and a second one to repair a version-record-only trustdb (the example file).