Also applied to gpgme.

Since there is no problem with libgpg-error 1.43, I applied it to other libraries: npth, libassuan, libksba, and ntbtls.

I'll fix regressions: failures of pubkey and pkcs1v2.

We will have rnd-getentropy.c

Applied and pushed symmetric algo for basic.

Let me clean up rndlinux.c for current use case, at first.

I decided to use 3.3.0 disabling pthread feature.

Applied parts except part 2.
The part 3 are modified version, so that memory can be released correctly.

Firstly, applied uncontroversial part in rC976673425784: doc: Reference the new FIPS 140-3

I use unsigned long instead of nfds_t, so that a user doesn't need to include <poll.h> when he doesn't use poll/ppoll API.

Don't apply tests/gpg/t-support.h, it's only for testing this patch.
When test, before running 'make check' please do:

Update to include the change of tests.
Also include a change for tests/gpg/t-support.h to run tests under artificial environment.

For libgcrypt, it was fixed in: T5637: Use poll for libgcrypt (support more than 1024 fds)

Check for FIPS has been added. (1) and (2) were solved.

Its copyright notice in upstream now refers LICENSE file, which requires some arrangement.

I work on gniibe/jitterent branch.
I realized that full featured jitterentropy now requires pthread. Timer-less mode uses threads for entropy. This is not good for libgcrypt use.

Sorry, I have been confused and it took time to understand issues.
Indeed, there are (at least) four issues.

I think that this is due to support of UTF-8 codepage problem by console.

I put my initial try by rG752422a792ce: scd: Select a reader for PC/SC..

I found this: https://gist.github.com/PatrickLang/7be00ba46a43eca3ef64ffe64b494749#user-content-conflicts-with-windows-hello--virtual-smart-card

I understand the point in the 1706920, but I'm afraid that the patch itself would not be directly related for the bug. My point: It surely may catch a most serious failure, but not many failures (if we need to check here).

Perhaps, as a library (considering the benefit of users), it would be better to allow signature verification with SHA-1, to defer the decision to application.

I have a little concern for glibc 2.34 (which has dummy libpthread and all is actually in libc).

(3-1) is implemented: rCa23cf78102f3: cipher: Reject SHA-1 for hash+sign/verify when FIPS enabled.

For a programmer like me, it is easier if the behavior will be:

It was fixed in: rPTH223e59f992f9: build: Define _NPTH_NO_RWLOCK when we can't find pthread_rwlock_t. and rPTH09a12a679ec0: Fix how we expose rwlock API.

The problem is that the SHA-1 as a digest algorithm itself is allowed in FIPS mode (for non-cryptographic digests), but using it as part of approved signature scheme is not allowed

The current code is inconsistent about its behavior: how non-approved digest algos are supported or not when FIPS enabled.

If .fips will mean FIPS 140-3, why not the following patch?

diff --git a/cipher/sha1.c b/cipher/sha1.c
index 3bb24c7e..cb50ef66 100644
--- a/cipher/sha1.c
+++ b/cipher/sha1.c
@@ -759,7 +759,7 @@ static gcry_md_oid_spec_t oid_spec_sha1[] =

I created T5665: libgcrypt : Restrict message digest use for FIPS 140-3.

Let me move this ticket as DONE (now Testing status), as the subject was solved (MD5 and soft/forced/inactive things).

I investigated if the possible change above (if applied) constitutes an ABI change: Indeed, it will be an ABI change, and an API change; code should be modified and build.

Sorry, I was wrong. We don't need any changes.

I am going to implement rejecting SHA-1 through new API (hash+sign, hash+verify).

It seems for me that the patches to random/ was written in old days.

• Now, we have getentropy in libc
  • This is most reliable one
  • better than urandom, because it may block when kernel is not yet seeded
  • better than random, because it never blocks once kernel is seeded
• So, the real path in rndlinux.c is actually, call to getentropy
• No access to /dev/random or /dev/urandom any more, in fact
• Although old code remains, non-touched
  • like use of syscall when getentropy function is not available

Add doc in gcrypt.texi.

Thank you. Applied.

Thanks for testing. I pushed a fix for my typo: rPb713f31c5b04: curses: Fix the previous commit.

I don't know if it's same in your case, but to fix my case, I pushed a change rG48359c723206: dns: Make reading resolv.conf more robust.

I managed to create a case. Put a line:

BTW, in your screen shot (log is preferred here), it shows 1c00, that must be actually written as AAAA (0x1c). In the bug T3803, we saw byte sequence like that, additional 00 was added then resulted malformed DNS packet.

OK, let us start discussion by applying the patch first.

Applied the RSA part.

Ah, other possible case is .. in hostname.

It's hard to investigate your problem, with no information of host for the query.
I mean, there is no case to replicate (for us).