Lot's of things changed in the meantime.

HKP keyservers are anyway out of fashion and thus we won't put anymore effort into his part of the code.

Lot's of changes since 2.4.

Eva and me tested this using our 2.2.42 release candidate on Linux and
on Windows and were not able to replicate your problem.

Actually, a GUI to maintain the keys in an LDAP would be helpful for many sites.

Instead of all the debug options, please use

From my practical expexperience, @ebo's suggestion will work best for me. The other thing I have seen is to not use -signed but to append the initials of the signers.

gpg -v -K does not require a pinentry. You can check this by adding debug-pinentry and log-file /some/file to the gpg-agent.conf - you should not see any pinentry invocation.

Well, even out new versions.gnupg.org uses a shorter hash. Better get that released asap.

I guess you need to wait until we do a new release. If your company relies on this software it might be a good idea to enter into a support contract as other do.

For Windows things are actually more complicate. It seems to be common practise of sysadmins to provide PAC files which are used to map URLs to proxys and to decide whether a proxy is to be used at all. Fortunately Windows provides an API to find the proxy for a specific URL. We should use this.

The site is on purpose w/o Javascript which might be the cause for things you reported. But I agree that the tab order is not as one would expect.

See also T4365 and rGb912f07cdf (gnupg-2.2)

gpgconf --show-codepages ist just a debugging aid. We use the code pages only for output to the console. The problem we see here is about log messages and they are always send as utf8 to stderr or the pipe used instead - without any translation.

Was already with gpgme 1.21.0. Note that I used the done column but in future a milestone would be more useful than that catch all "done".

Also fixed for gnupg22

@ebo: I just a did a test build: gnupg-vs-desktop-3.2.0-beta178-x86_64.AppImage in my directory

This has been well tested during development and is thus ready for a release.

That should be easy on Unix but on Windows we have the nul nul: and iirc also /dev/nul.

ack

We have a fix for now and thus I lower the priority. Given that EasyPG mimics the GPGME API we should here also use another pipe to convey the passphrase (e.g. for symmetric encryption).

I don't see a value to do this for 2.2 and introduce a regression with that.

@iklocker: Which gpg bug to you mean?

Seems to be solved in the current version (vsd 3.2.0-beta178).

It might actually be useful to have an random number API in gpgme. When we do that we can also add a way t search for random numbers with an upper limit in each octet.

Bugs goes back to 2002 where we stopped checking trust for keys without any signature. This was really useful but has this strange behaviour.

BTW, with one of the recent gpgme fixes we now get

$~/b/gpgme/tests/run-keylist  --extern --verbose foo
run-keylist: file /home/wk/s/gpgme/tests/run-keylist.c line 414: <Dirmngr> No keyserver available

which is what users (and kleopatra) expects.

Note that for vsd we also need to change our default configuration file. The new "none" value provides a better error message than the old default of assuming that the AD carries the keyserver (which it does not in practise).

Thank you.