In T6229#163870, @werner wrote:

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.

Pleaee have a look at https://dev.gnupg.org/T5790, i added a patch.

Attached you find a patch to this issue. This Patch sets the "keypair" attribute to the keys 0x82 to 0x95 unconditionaly.

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.

I tried to clarify the comment in the following merge request. Feel free to pull it from there or adjust if it is too verbose or missing some points:

Hello,
I'm having the same issue here, and as I've an image in the signature of my emails the signature is not visible at all when I sign the messages.
The image attached seems to be well included in the attachments and the image is readable.
Thanks,
isundil

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

I am attaching one last log I have while trying to use the SC-HSM and using the debug options mentioned. From what I understand, the keys and certificates are recognised by scdaemon, but, for some reason, they don't show up in gpg --card-edit --expert or in Kleopatra. Having AES symmetric keys also causes the PrKDF to show up as invalid.

Also applied to 1.10 branch.

In rCa6a6e94027abf18a51f5f93bf9fb2cfe5496bdf8#74835, @werner wrote:

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

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

Patch applied to master, thanks.

In T6218#163787, @gouttegd wrote:

Does the latest Scute require an instance of gpg-agent and/or scdaemon running to work?

Yes. Scute relies on those to interact with the token.

Does the latest Scute require an instance of gpg-agent and/or scdaemon running to work?

One nit that I overlooked initially is the memory leak, which is fixed with the following 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.

With a gcrypt not claiming compliance you should not get the status compliant or not but GnuPG should error out with forbidden.

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.

Merged the changes in t6002 branch into master.

Applied and pushed the change from @joeyberkovitz in rG3257385378bb: dirmngr: Interrogate LDAP server when base DN specified..

That sounds quite cool.

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.

I was indeed using version 1.5.0 for testing, but I wish to clarify the purpose of Scute in my setup before proceeding.

Perhaps --full-generate-key should provide more algorithm choices, then, e.g. ed25519?

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.