Install GnuPG 2.2.32 on top of Gpg4win 3.1.16 to fix the problem.

The most of the stuff about boot blocking was discussed in the bug https://bugzilla.redhat.com/show_bug.cgi?id=1569393 (private). There were some bugs in our patches, but also some issue in the kernel that locked the boot process (in FIPS mode).

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

The key was generated without a passphrase.
Removing the pinentry-mode loopback parameter did not result in any popup at all but just gave me the below result:

Does the key have a passsphrase or somehow the empty string as passphrase?
If you don't use lookback mode: does the pinentry pop up?

Thanks for responding to this issue. The GnuPG2.29 is the version of GnuPG that came with the RHEL8.2 server provided for by our server engineer team(might be part of an RPM package the installed). Do you know if this issue got fixed in the later versions after that?

(I edited the report to make it readable, but did not yet looked at it in detail)
I wonder why you are using a decent libgcrypt but a 3 years old GnuPG version?

By the way he is the version details of gpg2.2.9_rhe8 that I used:
fubar:testingGPG2.2.9-> gpg2.2.9_rhel8 --homedir gnupg2.0 --version --verbose
gpg: WARNING: unsafe permissions on homedir 'TESTING_GPG2.2.9/gnupg2.0'
gpg (GnuPG) 2.2.9
libgcrypt 1.9.4
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later https://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

I think we can close this bug. The warning will now only be printed as part of the the regression test and after all it is just a warning.

Will go into 2.3.4 which will also silence the noise of not being able to read it. The major reason for this code is to allow building an AppImage.

Thanks for the patch. That is sufficent. I added you to the Contributor group, though.

OK. Sorry for the noise. I got a clarification that the test is no longer needed so closing this issue.

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

The thing is that any n.m.k-something version should behave versionwise the same as n.m.k. That is okay, because beta versions etc are not considered to be released. This is required to allow testing beta version _before_ doing the release.

From the FIPS Certs draft for RHEL 8.5, I have the following sentence:

Thanks for creating the issue.

It seems like this warning does break some usages of gnupg on macOS.
We found one when packaging this in Homebrew: https://github.com/tadfisher/pass-otp/issues/147

Hello Mr. Koch,

Thanks.

@Reiner: Any news; were you able to run the the command with redirection to some file?

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).

Fair enough. Unfortunately, the separation is not completely clear from the dist git history, so please, excuse any inaccuracies I will provide here. I will try to reference particular bugs so we can get back to them if needed:

The notation data is filtered through notation_value_to_human_readable_string by mistake, note the [ not human readable (32 bytes: .... ].

So what is your bug report? Note that the NOTATION_FLAGS are only printed for human readable or critical notations.

At this moment, we agreed on keeping the current behavior and not allowing the SHA1 for verification either. But we might need to revisit that in the future if this will cause issues. Or we might go the way of switching the service to non-fips if needed, rather than creating some more middle ground.

Thanks! I was able to compile the current source code of npth (1.7) (with gcc 7.1. and ldd (GNU libc) 2.3.2 ). The error error: unknown type name ‘pthread_rwlock_t’ didn't occour.

The below change makes the function report a general error if gpgconf didn't write any output on stdout:

diff --git a/src/engine-gpgconf.c b/src/engine-gpgconf.c
index 28f91158..21211366 100644
--- a/src/engine-gpgconf.c
+++ b/src/engine-gpgconf.c
@@ -1245,6 +1245,13 @@ gpgconf_query_swdb (void *engine,
         }
     }

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.

Thank you for having a look into that. The change looks fine, but I need to get some clarification about what "Legacy use" means for "Digital signature verification" in the Table 8 of https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf

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

Okay, any thing else missing in nPth?

(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.

Hello @gniibe, you did the last work on nPTh. Would you be so kind and look into this?

Thanks for the clarification. So it's just a matter of not emitting the warning I guess?

gnupg_bindir() uses unix_rootdir() falling back to the builtin configure time path if unix_rootdir() returns NULL. So, there is no difference.

In T5433#151041, @gniibe wrote:

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

When using gcry_pk_hash_sign and gcry_pk_hash_verify, approved digest algos are guaranteed when FIPS enabled.

Yes, it's a user of the function who supplies HD (handle for hash). (I had wrong assumption HD could be with non-approved digest algo.) But it is needed for the user to enable the HD and to feed message beforehand. At that stage, non-approved digest algo must fail.

This has not been set high on the priorities, because keyserver access works for most with Gpg4win (and thus GnuPG) on windows. A recent exception has been occurred about a month ago with Let's encrypt expired root certificate. So currently for Gpg4win 3.1.16 you need to update to a newer GnuPG (Version 2.2.32 at time of writing), by installing the simple installer,e.g. https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.32_20211006.exe

I second this. This is problematic on (Free)BSD too, where /proc is usually optional and might not be mounted at all. I concur that this should be silenced if not running in debug mode.

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).

( No need to certify the DSA things)

Urgs, I already implemented this:

On macOS _NSGetExecutablePath could be used, but iiuc this requires linking against dyld. For other OSes we would also need more code. I doubt that this makes a lot of sense these days; but we should come up with a solution, even if that means we need an envvar to specify the location of that open gpgconf.ctl file.

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

Thank you. Applied.

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.

In T5617#150908, @gniibe wrote:

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

I have wondered if introducing another state in FSM would be needed, because:

dots are not allowed in hostnames.

OK, I'll gdb in there to see what happens. My domain is a classic pgp.domain.com

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).

No, the error is harmless. I guess it shouldn't be printed (except when debugging).

We now require a way to get the actual image of a process. For macOS the BSD method is used and we obviously need to find another way for macOS.

Fixed in 2.3.3.

Thank you again.

Excellent thank you.

I won't anymore follow the path of first doing a test install. That is way to hairy in respect to "make distcheck". Change is already in my working directory.