If it confuses users, we can apply something like this:

diff --git a/tools/gpgconf-comp.c b/tools/gpgconf-comp.c
index 2a5087e1f..12916a64e 100644
--- a/tools/gpgconf-comp.c
+++ b/tools/gpgconf-comp.c
@@ -93,7 +93,9 @@ gc_error (int status, int errnum, const char *fmt, ...)
 /* Forward declaration.  */
 static void gpg_agent_runtime_change (int killflag);
 static void scdaemon_runtime_change (int killflag);
+#ifdef BUILD_WITH_TPM2D
 static void tpm2daemon_runtime_change (int killflag);
+#endif
 static void dirmngr_runtime_change (int killflag);
 static void keyboxd_runtime_change (int killflag);

Thank you for your confirmation. Closing.

Fixed in GnuPG 2.3.1, so, add the tag for GnuPG 2.2.

is more important

I just realized that my example is incorrect. It doesn't make sense to support multiple issuer subpackets on self signatures. But it is useful to do so on binary signatures and third-party certifications. Here's a better example, which gpg correctly supports. As such, this issue should be closed. Sorry for the noise.

In T5395#145417, @gniibe wrote:

I can't see null pointer de-reference (you claimed) in [4/5].
Could you please elaborate?

It's in 1.9 already.

it's in 2.3.

Applied.

This has been applied already.

I applied 1,2,3, and 5 in rKfbb1f303198b: Fixes for static analysis reports.

I can't see null pointer de-reference (you claimed) in [4/5].
Could you please elaborate?

IIUC, with libgcrypt in LIBGCRYPT-1.8-BRANCH (not yet released) and libgcrypt 1.9.3, the build process works well (the problem with SIP has been handled).

In T5401#145379, @werner wrote:

You can't use an EdDSA as subkey for encryption. Encryption is the default for a subkey unless you provide key usage parameters. Yes, we could flag this as an error, but I won't give it high priority.

Yes, this is an edge case very unlikely to be encountered. The odd thing is the generated "ed25519" subkey does somehow encrypt and decrypt without issue.

You can't use an EdDSA as subkey for encryption. Encryption is the default for a subkey unless you provide key usage parameters. Yes, we could flag this as an error, but I won't give it high priority. I would anyway suggest to use

Thanks, that was right in time for this weeks 2.3.1.

aheinecke: I agree, we should not port everything back just because we could do that.

Has been released with 2.3.0 and we better open a new task if problems show up with v5 key. I am pretty sure that there will be a few v5 key problems after they get in real use.

This has been released with 2.3.0 and no relevant problems have reported in the last two weeks, thus closing.

t-link does not do antthing useful, anyway. I don't think it is justified to add dlopen stuff. Running real test is anyway a manual action; for a full test automation we would need to emulate all supported cards.

the t-link test should dlopen scute.so in runtime rather than link against it in build-time.

This has been fixed in version 2.2.16.

As of slibtool commit 9c5ba5eb, scute now builds out of the box. I'd still recommend taking the above into consideration, though.