Thank you for your log.

Please show us the log of configure, not just the result of the failure.

If you see wrong result for the decision of the HAVE_LOCK_OPTIMIZATION (for running the test), it's better to contribute to gnulib (https://www.gnu.org/software/gnulib/) for the detection of thread features.

The branch gniibe/v5/448 has the implementation.

To be conservative, it's better to output non-zero-removed signature.

My proposal is applying SOS (MPI with leading zero octets) patches, for 2.2, because there may be existing keys with SOS already.

It's not yet solved.

Reading the documentation of musl, it seems that there are no equivalent to detect if an application is single-threaded or not.

In the libgpg-error implementation, it may skip synchronization when it can detect an application is single threaded. The t-lock-single-thread test checks if it really skips as intended.

Thank you.

Last week:

• libgcrypt
  • Merge and fix jitter entropy update: T5523
    • no pthread
    • using independent SHA-3 implementation which comes with jitter entropy itself
    • Our local patch to use non-secure memory for memory access jitter
  • Fix: T5692
  • random deinit: T5636
    • How about extending gcry_random_close_fds? Intended use cases are: (1) resource release after fork, (2) clean restart after selftest
• libgpg-error
  • fix build dependency
  • Created T5698: w32: Support poll with FD backend

Part 1 was applied. Part 3, Part 4, and Part 7 are irrelevant now, because we now have rndgetentropy which doesn't use device.

I don't know how runtime (of mingw) is thread-safe, but if it is, it should work well.

Thanks for your report.

It was in the middle of merging jitterentropy. Please see T5692 (newer jitterentropy uses pthread by default, which was disabled now).

Fixed, with using normal memory for ->mem.

->mem is just used to measure the difference of memory access.

It found that newer jitterentropy uses larger mem (128KiB), while older uses 2KiB.

Pushed to master.

In the documentation, I found:

Last week:

• openpgp-dt
  • quantum computing is out of scope for current crypto-refresh, it will be next
  • interoperability by testing with sop (Stateless OpenPGP Command Line Interface)
  • NIST standards don't have OCB, but currently they work for lightweight encryption
• libgcrypt
  • Change reference in NEWS to CVE to clarify confusion
  • rndgetentropy.c
  • T5393
  • T5512: Fixed regressions (pubkey, pkcs1v2)
• other libraries
  • apply change in T5610 of libtool for macOS
• scdaemon
  • T5644: white list is too strong, so only one entry for that
• gpgme
  • fix build for Android
• libgpg-error
  • fix dist/build, etc.

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;

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.

Under C11, it seems OK (strncmp).
https://stackoverflow.com/questions/38878195/does-this-usage-of-strncmp-contain-an-out-of-bounds-read

I applied most of gnupg-coverity.patch.

• Part 1 is not applied; It should be handled later.
• Part 2: applied
• Part 3: applied
• Part 4: applied, but spell fixes not require ChangeLog entry
• Part 5
  • ecdh part is fixed differently
  • export.c part is not applied for now, because of semantics/interpretation of strncmp; POSIX says differently although it says it's ISO C standard which defines. https://pubs.opengroup.org/onlinepubs/9699919799/functions/strncmp.html
• Part 6: applied
• Part 7: applied, but empty initializer is GNU extension (or the way of C++), so first 0
• Part 8: applied
• Part 9: applied, but one more fix