In the documentation, I found:

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.

In T5687#151853, @werner wrote:

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

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.

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.

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

Okay, I revisited the code:

The internal hashing of ed25519 is not used by OpenPGP but instead we pass the hash of the message to the ed25519 function and thus to the card. Pushing a message through a card is a no-go - way too slow for any normal sized message.

Since hashing happens on-card for ed25519 I'm not sure what limits gpg wants to impose, currently the data is passed straight through and scdaemon will happily try to send more than 255 bytes of data as a short apdu here. My patch is probably not correct, I assume it needs to care about cardcap.ext_lc_le and chunking as well.

That does not seem to be right. You don't need 255 bytes for an ECC key. It would be best to get scdaemon logs simialr to the gpg-agent logs. Set "debug ipc,cardio" into scdaemon.conf.

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

I just wanted to add one more note that i just found out that the tests --disable-hwf or gcry_control GCRYCTL_DISABLE_HWF have no effect in case the global_init() is called from constructor.

Friendly ping @werner

We will have rnd-getentropy.c

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

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

Fixed and tested on Linux. Thanks.

I suppose you have rebooted the PC after installing GnuPG 2.3.32. Just to make sure. And double check that there is only one dirmngr.exe with version 2.2.32 installed on your system.

I did a complete reinstall after cleaning out the complete system incl. registry.
No change in behavior of Gpg4win.

THX for the quick reply Ingo...

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