[Merging didn't work]

The other key slots are claimed to be used for expired or archived keys as you rightfully mention. We need to figure out the real world semantic behind this before we can repurpose such keys.

That's more than sufficient. Thanks.

A minor clarification in the code comment would be enough. Something like: Some non-standard kernel return only 32 bytes of strong entropy to satisfy current FIPS requirements.

Yes, that's probably right. I talked to the vendor and they were nice enough to send us specs and samples. However, without a strong business case support for these cards we can't prioritize this work.

Most PCKS#11 drivers are proprietary software which do not fit well into a free software system. Thus we avoid them. And of course we provide pcksc#11 support: Install Scute. There are no workarounds like alternative gpg-agent's - those things don't work reliable and are not supported.

This is a duplicate of T6070. Please wait for gnupg 2.3.8

Why is that not stated in my man page which knows about kernel 3.19? Is that a regression or a RedHat specific patch?

Indeed, the status line should not be emitted in this case. Thanks.

Let's don't forget that we need to have a sig_class replacement.

This is not easy to fix because it would break the GPGME API. Here
are the values we can expect:

I assume this is gpgme master. Please write proper bug reports.

Justus, you should know how to write a proper bug report. Please do that and don't just paste some more or less random output here with just hint that Libgcrypt is not compliant. tia.

This is a debug option; I see no use case for this.

Add --expert and use a decent version of GnuPG. 2.2 is our long term support branch and is not the current stable production version (which is 2.3.7)

Actually we developed PIV support to allow the use of PIV X.509 certificates and OpenPGP keys with Yubikeys. In fact, GnuPG is able to switch between the Yubikey PIV and OpenPGP applications on-the-fly while keeping their PIN verification states.

Sorry, this as been discussed ad nausea. We try our best to help people not to use useless and harmful (e.g. performance of the WoT) algorithm choices.

Yes, I meant to use Scute as pkcsc11 module for pam_pkcs11. Thanks for explaining more verbosely what I meant.

My poor old laptop - its RAM will now have a hard time to run the huge tests ;-)

BTW, I have also in mind to use an AD entry to figure out the used keyserver. It turned out that people don't like to modify the schema of their AD but instead use a separate LDS.

There is a reason why pcsc-shared is not the default ;-). Please try using Scute (best the t6002 branch until it has been merged) as pkcs#11 provider instead of pam_pkcs11. And you should of course use the stable version of GnuPG and not the LTS (2.2).