The use cases are:

• oPassphraseFD for gpgsm, gpg
• oStatusFD for gpg-auth, gpg-wks-client, gpg-card, gpg-pair-tool, gpgtar, gpgconf, gpgsm, gpg, gpgv
• oLoggerFD for gpgsm, gpg, gpgv
• oAttributeFD for gpg
• oCommandFD for gpg
• oOverrideSessionKeyFD for gpg

Removed parent task because this issue doesn't really block T5478: Kleopatra: Performance problems decrypting and encrypting large Archives.

ready for testing

Done. Can be tested and closed with T5478: Kleopatra: Performance problems decrypting and encrypting large Archives.

ok, then this is resolved

Yes, that was the intention eva reminded me that I had not done this yet, but the next releases of GnuPG VSD will have action/help_contents=false in their action restrictions.

I think that for VSD the Help action is disabled via the configuration because you have alternative documentation to the Kleopatra Handbook. @aheinecke?

Which is the same URL as the F1 Help page thus probably opened via QProcess?

It works, including the nice message box, for most links in the Help menu, but not for the Kleopatra Handbook.

Thank you. Now, I see the reason for conf/ sub directory.

See T4168 and rMecfa48fffa9 for the reason why we need this conf directory. Thus (1) is not an option.

Thank you for having a look into that! The proposed patch looks good. Should we have this change also in master?

I vote for (1). All other GnuPG projects put config.h[.in] in the top directory.

Thank you.
Applied to master, 2.4 branch and 2.2 branch.

Thank you.
Applied to master, 2.4 branch, and 2.2 branch.

rGb1ecc8353ae3 is just what I meant, so that we can recommend such an option in the future as a workaround until a new update becomes available which supports such an extension.

Nah, the description for that extension is pretty strict and I won't feel comfortable to just ignore it. BTW there is also T6398 (nameConstraints) which needs support. But for debugging a ignore extension makes sense.

For support reasons I would say that it might make sense to also ignore the extensions from "ignore-cert-extension" when checking CRLs?

works

Here is a possible change (... to master, assuming it's good to support use case of RFC 8702):

diff --git a/cipher/keccak.c b/cipher/keccak.c
index 22c40302..76e08cb5 100644
--- a/cipher/keccak.c
+++ b/cipher/keccak.c
@@ -1630,8 +1630,8 @@ const gcry_md_spec_t _gcry_digest_spec_sha3_512 =
 const gcry_md_spec_t _gcry_digest_spec_shake128 =
   {
     GCRY_MD_SHAKE128, {0, 1},
-    "SHAKE128", shake128_asn, DIM (shake128_asn), oid_spec_shake128, 0,
-    shake128_init, keccak_write, keccak_final, NULL, keccak_extract,
+    "SHAKE128", shake128_asn, DIM (shake128_asn), oid_spec_shake128, 32,
+    shake128_init, keccak_write, keccak_final, keccak_read, keccak_extract,
     _gcry_shake128_hash_buffers,
     sizeof (KECCAK_CONTEXT),
     run_selftests
@@ -1639,8 +1639,8 @@ const gcry_md_spec_t _gcry_digest_spec_shake128 =
 const gcry_md_spec_t _gcry_digest_spec_shake256 =
   {
     GCRY_MD_SHAKE256, {0, 1},
-    "SHAKE256", shake256_asn, DIM (shake256_asn), oid_spec_shake256, 0,
-    shake256_init, keccak_write, keccak_final, NULL, keccak_extract,
+    "SHAKE256", shake256_asn, DIM (shake256_asn), oid_spec_shake256, 64,
+    shake256_init, keccak_write, keccak_final, keccak_read, keccak_extract,
     _gcry_shake256_hash_buffers,
     sizeof (KECCAK_CONTEXT),
     run_selftests

Reading RFC 8702, I realized that it defines the hash size in the use of CMS as: SHAKE128 : 32-byte SHAKE256 : 64-byte.

Applied rC8cdd0d353e19: cipher:pubkey: Check digest size which should not be zero. for 1.10.