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.

OpenPGP requires the P < U property and gpg does also. In some parts of the GnuPG we re-calculate the CRT parameters but not in these code paths. Right, a better error message would be appropriate. I'll turn this into a feature request.

Fix for this issue landed RNP master, and will be included to the RNP v0.16.0 release.
Within fix:

• new keys will be generated with correctly tweaked bits
• using secret key with non-tweaked bits would issue a warning
• CLI command --edit-key [--check-cv25519-bits | --fix-cv25519-bits] added, allowing to fix older key

I push a change: rC070935965763: build: Use KEY_FOR_BINARY_CHECK for --enable-hmac-binary-check..

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

Please ask on a mailing list etc. This is a bug tracker and pnly very few people are reading your report.

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.

Fixed in gpgex 1.0.8

Sure they don't get created - they are optional.

I did in fact check --status-fd before, but I'm not sure whether it gives me the information I wanted.

In that case maybe GetUserDefaultUILanguage. Thank you for considering.

Thanks for the info.

Please use the --status-fd interface. This yields all the info you need. An exit code is not distinct enough for such purpose and you need to check the status lines in any case. For scripting gpgme-tool or gpgme-json might be useful as well because they do all the nitty-gritty parts of using gpg correctly

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.

There won't be any other 3.1 release - install GnuPG 2.2.32 on top of Gpg4win 3.1.16

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.

My experience on a Window 10 system (with Gpg4win 3.1.15 which has GnuPG 2.2.27) was, that removing the expired root certificate did not help with https://keyserver.ubuntu.com and the intermediate certificate was not in the windows store, so it could not be removed.

Sure.

Removing an intermediate cert from your local system doesn't help because any correctly configured server will send you all necessary intermediate certs together with the server cert. You'd have to remove the expired root certificate instead (see Workaround 1 on https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/). The problem is that this will break certificate verification for any servers that still use the old intermediate cert, e.g. keyserver.ubuntu.com.

And it shows

Thank you so much for your explanation.
I just want to try with older version. Because when I try to run

The LE web site has instruction on how to do this. However, it is complicated and depends on your system. The intermediate cert you listed is signed by the expired old root cert. If you remove this intermediate cert the other root cert will be found and we are done. The old LE certs had a 4 tier chain and the new one a 3 tier.
See https://dev.gnupg.org/rG341ab0123a8fa386565ecf13f6462a73a137e6a4 and https://letsencrypt.org/images/isrg-hierarchy.png

One problem I see is that keyserver.ubuntu.com delivers a problematic intermediate(?) certificate:

If there is no easy way to install a new version of GnuPG, e.g. for Gpg4win or for GNU/Linux distributions: It may make sense to have instructions for the workaround ready.

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?

Pushed the change: rC082ea0efa9b1: cipher: Add sign+hash, verify+hash, and random-override API.

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.

Please update to 2.2.32 if you have problems with keyservers etc.

Backported to 2.2.32

We have been hit by the Let's Encrypt root cert switch. Thus a fixed version will soon be released. See T5639 for details of the problem.

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