One more nit regarding to the test is the format string for size_t which was using %d instead of %zu. This is fixed by the attached patch:

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

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.

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.

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.

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.

Which version of Scute are you using?

The specs https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf page 10 says specifically:

Using Scute as a drop-in replacement doesn't currently work. Perhaps my config needs more adjustments than just:

module = /usr/lib/x86_64-linux-gnu/scute/scute.so

I've tested the different hw implementations (amd64, arm64, s390x) and they are all ok.

Thank you for your report.

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

I think Werner may have confused pam_pkcs11 with gnupg-pkcs11-scd. :)

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

The test looks good. I hope I changed the API in all the hw optimized implementations.

I'm not sure what you mean with using Scute as PKCS#11 provider instead of pam_pkcs11, as pam_pkcs11 is not a provider but a user of PKCS#11

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

Fix looks good to me. This could be tested with new long running test (tests/hashtest) that would allocate 4GiB+ pattern block for inputting to gcry_md_write.

This still did not seem to help me in making the tests working on Fedora with git master. I am still getting wrong paths to the gpgconf

gpgscm: error running '/root/gnupg/tests/tools/gpgconf': probably not installed

There is a full reproducer and more complete log in https://bugzilla.redhat.com/show_bug.cgi?id=2089075#c11

We should close this. The recent fix in 2.2 and the forthcoming 2.3 does everything we want. In the meantiime or if further problems turn up, --ignore-cert is a good workaround.

works

Sorry, you need to wait for gnupg 2.3.8. It's next on our shortlist.

@ikloecker Thank you for the pointer.
When people will use C23 compiler, there will be no problem (even with non-fixed version). That's good. :-)

Finally had some time to look into this a bit more.

In T6209#163363, @werner wrote:

Also the use of the standard-resolver is not a good idea because it does not work with Tor.

The use of

That particular bug seems to have been solved a long time ago. I stumbled upon up while fixing a DP bug today.

I suspect that this has to do with your usage of tor (or gpg thinking that you use tor) because in dirmngr/dns-stuff.c I found

if (tor_mode)
  return gpg_error (GPG_ERR_NOT_ENABLED);

and all other places returning GPG_ERR_NOT_ENABLED seem to be related to S/MIME.

Actually, noreturn isn't a keyword. The keyword is _Noreturn. noreturn is a convenience macro, which is provided in the header stdnoreturn.h. Funny enough, _Noreturn and the macro noreturn will be deprecated with C23 in favor of the new attribute [[noreturn]]. :-)
https://en.cppreference.com/w/c/language/_Noreturn

Pushed similar changes for GnuPG and libgcrypt (which are actually harmless as it is internal use, not exposed header).

Awesome, thanks all! From an end user perspective that would be a perfectly acceptable outcome, the warning just serves to confuse people. Appreciate the help!

I have created the spin-off T6202: Kleopatra: Suppress errors of WKD lookups to deal with not bothering Kleopatra's users with error messages when doing a WKD lookup in the background. This task is for improving dirmngr.

The workaround is easy: Change the passphrase , export, import and then set a longer passphrase again.