You should not fix stdout with stderr. Granted we could fflush stdout after a line, but rsh is dead and so all software can distinguish between them.

I t could print a warning for a non-existant homedir

It is actually questionable whether PSS is a better padding scheme than PKCS#1, see
https://www.metzdowd.com/pipermail/cryptography/2019-November/035449.html . PSS seems indeed be rarely used; quoting Peter from a followup on his writeup: “If I get time over the weekend, and I can find a CMS message signed with RSA-PSS, I'll create a forgery using xor256.”

As you surely known GnuPG requires its home directory; in particular when using the gpgconf to manage the config options. Thus I can't see what to do other than error out. gpgconf needs to know the location of the config file; if it is containign diretcory is not existant it will fail anyway.

Okay, I recall that I have seen these Yubikeys. Can you tell me which GPG app you intended to use? I am not aware of any GnuPG ports to the iPhone.

keyserver-URL needs to be replaced with with a keyserver URL, like

hkps://hkps.pool.sks-keyservers.net

Supporting NFC tokens requires implementing secure messaging for cards. This is on our todo list anyway but has had no priority. I have a couple of Yubikeys but not done any work on NFC.

--auto-key-retrieves tries to find a key when verifying a signature. --locate-key however does the same as what -r does and locates a key for further use. If you don't what that, don't include a key discovery mechanism in the the auto-key-locate like (wkd in this case, which is anyway the default).

Arggh, gpgconf uses its own option parser so adding the global config file there will require some extra work.

All done in master with the latest libgpg-error (see T4859). There is always a global configure file in /etc/gnupg (or whatever "gpgconf --list-dirs sysconfdir" prints). The name of the configure file is the same as the user config file (gpg.conf, gpgsm.conf, gpg-agent.conf, ...) but for gpg.conf no versioned config names are used.

Internally only the long key id is is used thus the fingerprint might give a wrong impression. OTOH, to allow easy migration to future versions, extracting the keyid from the fingerprint is a good idea.

(I stripped the report down to its core)

Do not use arbitary libtool versions or use autoreconf - this is maintainer-only and any problems are not considered a bug.

Okay, we now have global conf files in master. The extra flags to ignore or force certain options will be added to libgpg-error.

and by that bypassing all key source tracking as done by gpg. In any case searching by name or mail address on a keyserver should not be done - at least not by a GUI tool as used by non experienced users.

The problem is not to check whether there is a connection but on how to decide whether something is a pool or an explictly added single keyserver and how often should we try to connect or read from it. Without marking hosts as dead the auto search features won't work well.

The proper solution is of course to use pkill instead of killall. SCNR.

Are you sure that you have only one secret key? (run: gpg -K)

The info from your report iis a bit scarce; we would need more to replicate this and also the version of the software and the OS you are running.

Yeah, this can be done.

The DLL libassuan-0.dll was not found or the system somehow found.
Do you have other versions of GnuPG or Gpg4win installed? Please search the system for copies of the above mentioned DLL?

Fixed in master and 2.2

Really interesting: The code didn't changed since since 2003 and the bug must have been there all the time. It does happen only for 25% of the certificates with CR and LF; the others have padding characters at the end '=' which is also an indication of the end of the base64 block. I wonder why this has not been reported more often; maybe because most people import binary certificates.

Thomas, please provide a sample certificate. I can't access the intevation site to see whether one of the links has the cert. And pretty please fix the wald certificates!

Older version of GnuPG had a rare bug in the keyring update code.

No, this depends on the version of Libgcrypt. Sorry, won't be documented or changed. Thanks for the report, though.