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.

In T6014#163086, @ikloecker wrote:

In T6014#163083, @aheinecke wrote:

I think it is problematic that the WKD errors are shown to the user at all. Doing some random searches gives an error each time something can't be accessed.

Can you give an example other than the Syntax error issue? So far, I haven't seen any errors when doing random searches with ASCII-only "email addresses". I simply get zero results, but I don't see error messages, e.g. if the host cannot be found.

Of course it could be refined to use the same host if there is only a relative URL.

That's for sure. See rGfa1b1eaa4241ff3 :

Does dirmngr maybe interpret the redirect reply /.well-known/openpgpkey/hu/enzdc18iy17uy9qb3pwm4ay9a1ga6mb3/ as URI? That would explain the error because without protocol the redirect reply is indeed an invalid URI.

Let me know if you want full logs, but here is the segment with more info.

@ametzler1 thanks for the feedback!

In T6014#163083, @aheinecke wrote:

I think it is problematic that the WKD errors are shown to the user at all. Doing some random searches gives an error each time something can't be accessed.

Thanks for your help analysing this problem.

I think it is problematic that the WKD errors are shown to the user at all. Doing some random searches gives an error each time something can't be accessed.

There is probably an umlaut or special character in <domain> or <user> which makes the URL invalid. If I search for "test@ä.de" I also get Syntax error in URI.

So looking through the logs it appears that it is trying a lookup against our domain, in addition to the key server we have configured.

If any notepad operation is canceled, then there shouldn't be any error messages or result widgets (the frame with the Close button in the screen shots) anymore.