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.

Bison used to be the de-facto standard yacc ;-)

I think that a simple way is defining a table (string -> token) by ourselves in yylex, not enabling %token-table.
(Then, we don't need to depend on the feature of string with %token, which is not supported by POSIX yacc.)

Note that I'm referring to file based keys, not card based.

I tested this on 2.3, and it doesn't seem to be fixed. When adding an existing ECDSA subkey I don't get the option to choose whether to make it a signing or encrypting subkey. Instead it only allows me to choose an encrypting subkey.

Thanks for your findings. I recall that I read this in the announcement and cursed about this new tendency in GNU to break long standing APIs.

Looks like yytoknum was removed from Bison in version 3.8: http://git.savannah.gnu.org/cgit/bison.git/commit/?id=1efe31185ff6b0bc22ff527098971bedf1ace5f4

Danke -

As long as we can't replicate this, it does not make sense to keep this bug open. Please re-open it if you run into it again in a replicatable way.

Problem/Bug still persists in current version (gpg4win 3.1.16) --> reopen

sorry for a confusion. We do not plan to certify DSA so disregard the second part of the patch.

Sorry, I just discovered that I had to click on "Save All" in order for the file to be actually stored in the disk and then it works.

Here it goes...

Please hit "mostra de registro..." link in the blue box and show us its content (you may want to check that it does not show sensitive data)

Thanks for the log, however, I would suggest to use 3.1.16 and try again.

Do we really need to support DSA in FIPS mode? I mean standard DSA and not ECDSA.

Argh, sorry for bugging. Clearing comment out - I simply missed fact that my tests are run with random messages, so with 5% probability another password will be interpreted as 'good' for the first SKESK.

Works for me:

$ gpg --version
gpg (GnuPG) 2.2.27
libgcrypt 1.9.4-unknown
Copyright (C) 2021 Free Software Foundation, Inc.
License GNU GPL-3.0-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.

The usual procedure for downgrading is

1. Uninstall the currently installed version
2. Install the older version

You should never ever downgrade. What is the problem with the new 2.2.32?

What do you mean by asking on a ML or on IRC for networking help?

Hi, I have installed 2.2.32, but still get the same error.

Thank you for your reply! I have updated version numbers and the used OS. I will try with GnuPG 2.2.32

I can't tell you why you get this error. However, since Oct 1 the keyserver access does in many case not work anymnore. This has been fixed in GnuPG 2.2.32, which I released a few minutes ago. You may install this on top of gpg4win 3.1.16.

Backported to 2.2.32

You mean Gpg4win. The solution for Gpg4win 3.1.x is to install the latest GnUPG LTS installer for Windows on top of the latest Gpg4win version. See
https://lists.gnupg.org/pipermail/gnupg-announce/2021q3/000464.html
Noet that there will very soon be a 2.2.32 to fix a problem with Let's encrypt protected keyservers (T5639).

Just for everbody else who might be waiting for a new release. Workaround is to simply use the previous version: https://www.gpg4win.de/change-history-de.html (3.1.15)

Thanks for the report. However, for 1.4 we will only apply important real world security patches. A brief review did not reveal any setious problems. Theoretical memory leaks will not be fixed. Note that your report also includes patches to parts of the code which are not anymore used.

Currently, I am using --lock-never config to avoid generating lock file as a workaround.