Well, the debug output

org.kde.pim.kleopatra: No update for: "Gpg4win-3.1.15"

and, even more clearly,

GPGME 20211019T134123 07DC        _gpgme_io_spawn: check: path=0x031deff0 argv[ 0] = C:\Program Files (x86)\GnuPG\bin\gpgconf.exe
GPGME 20211019T134123 07DC        _gpgme_io_spawn: check: path=0x031deff0 argv[ 1] = --query-swdb
GPGME 20211019T134123 07DC        _gpgme_io_spawn: check: path=0x031deff0 argv[ 2] = gpg4win
GPGME 20211019T134123 07DC        _gpgme_io_spawn: check: path=0x031deff0 argv[ 3] = Gpg4win-3.1.15

reveals that Kleopatra via gpgme ran the command

gpgconf --query-swdb gpg4win Gpg4win-3.1.15

i.e. that current is "Gpg4win-3.1.15".

I tried to reproduce this. Experimentally, I added P15CardWidget::searchPGPFpr() to OpenPGPKeyCardWidget, commented out the code that checks for an LDAP keyserver and called the function with a fixed fingerprint.

@ikloecker Note you can easily setup a test instance using one of Microsoft'S test VMs, see https://lists.wald.intevation.org/pipermail/gpg4win-devel/2021-October/001769.html

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

We should disable the menu button until it is fixed. I think it should be on the roadmap of 4.0 to have this working.

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.

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

Yeah, that will be helpful. Thanks. FWIW GnuPG 2.2.32 also lists PC/SC readers and not just the Linux default of CCID readers.

Yes, the text can be selected (with the mouse) and then be copied to the clipboard.

Version check is a data leak anyway and thus often disabled. Thus I don't see a risk for high value targets.

Just to be sure: Can you c+p the strings?

Adding GPGME_DEBUG with 9 to the logs, there is not much more to see:

With the following settings done as described at
https://www.gpg4win.org/doc/en/gpg4win-compendium_29.html

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

Kleopatra runs

gpgconf --query-swdb gpg4win 3.1.15

i.e. with the current version. Here, on Linux, I get

gpg4win:3.1.15:u::0:20211012T161328:20211019T103252:3.1.16:20210611T000000:0::

as result. The u in field 2 indicates that an update is available. The (current) code should work as far as I could see by a quick glance.

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.

Dialog showing the list of available smartcard readers:

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.

@werner can you prioritize?

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 would prefer to store legacy manuals on the web server. That is the easier solution.

Cool. Thanks.

In the global kleopatrarc add the following config entry to enable the symmetric encryption only option by default:

[FileOperations]
symmetric-encryption-only=true

@werner, because we have talked about it:

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

( No need to certify the DSA things)

I'm pretty sure that the first 3 messages are always decrypted with the first key because the passphrase of the first key is still cached. I don't think you can tell gpg to only use a specific key for decryption. The only way to make sure that gpg does not try to use the first key for decryption is to remove the private key of the first key. Alternatively, clear the cache after using the first key, but gpg might still ask the user for the passphrase of the first key.

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.

That looks like a support question. Please ask on a mailing list for help. Sorry, we can't do individual support here.

For completeness here's a screenshot that shows the situation on a TERM=sun-console text console with the latest code :

After thinking a little more about this issue, I am of the opinion that the best option here is to provide a compile time configure option :

It would be convenient if the -c option could be easily set in the gpg-agent.conf or in some configuration file for pinentry. The workaround that I use now to create a script that I can then use as pinentry-program is extra work because it requires an additional script.

The typo is fixed now and after pulling the latest sources from the repo and configure --disable-ncurses :

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: