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.

The new Yubikey 5Ci does NOT work with NFC, this is wrong. This Yubikey is delivered with two connectors: A lightning and an USB-C, see: https://www.mtrix.de/shop/yubikey-5ci/. The key can be connected to a laptop and an iPhone by plug-in. So the new Yubikey 5Ci does not require NFC at all. You refer to the Yubikey 5 NFC. This technology is not supported by developers because they do not have experiences there. With the plug and play functionality of a lightning connector it is easier and few application already exist (e.g. Yubico authenticator and several password manager in the professional edition). Hope this information will be useful for you.

To summarize: The DGN CRL uses a the RSA-PSS Padding / Signature Scheme. ( https://de.wikipedia.org/wiki/Probabilistic_Signature_Scheme )

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.

I don't have a Free BSD. Can you please try out the patch that I have appended to https://bugs.kde.org/show_bug.cgi?id=415168 ?

In my particular case, I want to find out if an email address has a publickey associated to it that is publically available anywhere. I do not want to import the key automatically. I used to use this command:

--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).

i'd be unlikely to ship anything as /etc/gnupg/gpg.conf or /etc/gnupg/dirmngr.conf just because of the mess that admins have to deal with when shipped config files change.

In T4861#132936, @dkg wrote:

0005 and 0006 from the debian distribution of gpgme.

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

@dkg You might find this interesting. Debian could do stuff in /etc/gnupg/gpg.conf or /etc/gnupg/dirmngr.conf without patching GnuPG to change some defaults.

Thanks for the report. Indeed I closed this as a duplicated. Thanks @dkg for pointing out the patches.

I pushed the change to master.

I think this might be the same as T4820.

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.

For the split OpenPGP / SMIME it's not intended to only work for BCC, its just the same mechanism I use internally.

I think this is a great feature to have. Thanks for working on it, @aheinecke .

I've just pushed ad55de70930543c1681b11e4bd624be074122b23 onto branch dkg/fix-4855 as a proposed fix, to permit --trusted-key to accept a full 20-byte fingerprint.

The idea of the implementation is that BCC recpients will get a mail with no other recipients. Because Exchange / Outlook handles the sending we can't do it more low level. We use the "Protected-headers" scheme to transfer the original To / CC headers.

In T4513#132777, @Valodim wrote:

But searching on Keyservers is also in my opinion not a common use case for Kleopatra users.

Thanks for engaging constructively.

Latest one (gnupg 2.2.19)

(I stripped the report down to its core)

Sorry but that really strange.
I need to regenerate those files.
Could you please describe what needs to be done to have proper version?

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.

In T4513#132770, @aheinecke wrote:

Werner could you maybe at least check for an internet connection, I don't know how to do it on Linux but on Windows it's easy because windows has API for that.