Here are the two test certificates mentioned in the commit log:

Pushed to master.

Pinentry: pinentry-curses (pinentry) 1.2.0
OS: macOS 12.0
Terminal: xterm-256color (via zsh in the default Terminal.app)

Additionally, poly1305-s390x.S is being compiled despite running/targeting a PC system:

We could use a new mode #define GCRY_GET_CONFIG_FIPS 1 with gcry_get_config:

What is your Pinentry version, which OS is that, and which terminal type?

With just implicit indicators, we would have to block all non-approved cipher modes and kdfs including the OCB mode and skcrypt, which would probably make gnupg2 unusable in FIPS mode, which is not our intention.

In the documentation, I found:

It would be the grey background text and no forced template, just as an input hint. And it would override the automatic detection of name / e-mail so that no wrong values are prefilled. This should help avoid unattentive users from creating a slightly wrong user id if their ad domain address does not match the e-mail.

Can you given a example on how this would look like. In particulr are placeholders some kind of forced template or just a grey background text?

Please also refer to https://github.com/microsoft/vcpkg/discussions/20755 where we discuss on how to approach GnuPG libraries for a native Windows compilation.

Also, and I should maybe have opened with it, the issues vcpkg has with your build system are currently tracked here, while my effort to build gpg-error natively (i.e. without relying on ShiftMediaProject fork) on all platforms is here.

In T5687#151853, @werner wrote:

FWIW, the gnupg installer comes with dll, header and import files. You may use them.

In T5365#151844, @gniibe wrote:

Let me clarify the use case of gpg-error.m4.

gpg-error.m4 is for GnuPG and its friends, where we cannot assume availability of pkg-config. Its capability is limited, and we don't pursue 100% compatibility of pkg-config.

No, our admin left us and took all scripts and docs with him. We need to set it up again. You better use this system anyway, patches etc on GitHib are not used.

GnuPG requires a Unix system to build. We do not support building natively on Windows. Sorry.

Adding the check on host side, I pushed the change: rGa575b0aba542: scd:openpgp: Support longer data for INTERNAL_AUTHENTICATE.

Let me clarify the use case of gpg-error.m4.

Or, we can use memcmp to avoid arguing semantics of strncmp, and make it a bit cleaner to avoid calling strlen multple times by put_membuf_str.

diff --git a/g10/export.c b/g10/export.c
index 98c4623cf..c7cfcfaa4 100644
--- a/g10/export.c
+++ b/g10/export.c
@@ -2133,14 +2133,15 @@ key_to_sshblob (membuf_t *mb, const char *identifier, ...)
   size_t buflen;
   gcry_mpi_t a;

In T5365#144688, @gniibe wrote:

If it is new, it may be the change of this commit rC8e3cd4c4677c: build: Update gpg-error.m4.

We know that problematic strncmp implementation: T5443
So, I don't blame Coverity. But I think that it's better to fix strncmp implementation.

The old code using sizeof(kek_params) (which is used for log_printhex) is incorrect; the value is the size of pointer to byte. It may works for 32-bit architectures, though.
On the machine which has 8 for a pointer, it will cause accessing wrong area, when DPG_CRYPTO is enabled.

I tried following the README instructions, but getting:

I just read https://github.com/gpg/libgpg-error/blob/master/README#L119 and realize this is by design...