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

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.

Major problem here (before the change) was that clock_gettime returned an error with no valid value of the time, which confuses gpg-agent's calibration of time. This occurred on (not newest) Solaris kernel, as it offers clock_gettime function in the library and CLOCK_THREAD_CPUTIME_ID constant in the header.

I mentioned the two POSIX getconf settings you referenced in those links, and the developer that implemented CLOCK_THREAD_CPUTIME_ID and a couple other CLOCK_THREAD types had this to say:

FreeBSD has _POSIX_THREAD_CPUTIME > 0.
GNU/Linux has _POSIX_THREAD_CPUTIME == 0, because older kernel doesn't support the system call.