The new bugs have been fixed in 2.3.3; see T5565.

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.

Is that really required? Should we wait what the conlusion of the WG will be?

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

On my new Windows 10 laptop I see a "Windows Hello for Business 1". Thus put everything with "Windows Hello" at the end of the list or skip unless a reader-port is set. IIRC there are device with "virtual" or "Virtual" in their name, they don't make sense for us either. I would also put devices with "SCM" or "Identiv" to the top of the list. In particular the substrings "SPR532" seems to identify the Identiv SPR332 which is what we use here and actualay a suggested reader for GnUPG VS-Desktop.

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.

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

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.

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

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

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

You should never ever downgrade. What is the problem with the new 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).

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.

Quite possibe and thanks for the report. However, this is a dev state of the things and thus not expected to work. I'll keep this open as a reminder for me, but in general I would prefer to get a report at the gnupg-devel ML.

Sorry, a hostname with slash is simply not allowed by IETF standards. Given that the hostname is part of temporary file names, you will run into an error. Yes, we could remap the slash in the mktemp function but there are lot of other plzces where the hostname is used and certain properties are expected.

Well this seems to be a gcc 4.2 bug. But well, forward declarations should go into a separate file so that tehre is only one place which would require changes. In this case it does not matter.

Requires a new option or command.

Sorry, I can't read all your comments about this. The percent escaping is correct and required. If you want to use the output in a script you can get it without percent escaping by using for example

Please don't, if you really feel like tha tis not resolved please re-open this ticket.

That pretty much looks like the other errors you have with Unicode characters - which we can't replicate.

This is all build from the same source. We could fix that but I'll give that a lo priority. Thanks for reporting.

That's correct - The output needs to be percent escaped.