The "at first" change done.

At first, I think that we need to change the way how libgcrypt rejects non-approved cipher/md/mac/pk.

We have full Unicode support on the command line since 2.2.28 (2021-06-10)

Please review these changes

Backport done but diligent testing is required.

Unfortunately same story for GpgOL v42.5.1. Tried disabling all non-Microsoft plugins, however to no avail. Signed and encrypted messages are shown as blank, whereas I can see the content of the signed e-mails in the Outlook web client and on my iOS device.

The new revision uses the python.m4 version from automake 1.16.5 and keeps Werner's modifications with the 4th parameter.
See also https://dev.gnupg.org/T3354 and https://dev.gnupg.org/rMff6ff616aea6f59b7f2ce1176492850ecdf3851e

I am not sure if you assumption about the intention is correct. After all, the openSUSE rpm build does use it for creating binding packages for all available python3 versions. If you remove the functionality to find all available versions ("flavors" in the openSUSE rpm packager lingo), the RPM build would need to introduce separate calls of configure and make.

Thank you for submitting the patch.

https://bugs.kde.org/show_bug.cgi?id=447326
This problem also appears for trojita.

The debug log was from gpg and not from dirmngr and thus it is not helpful. I also guess that an older dirmngr was still running, because the LE bug has been fixed in 2.3.4.

Format sys.version_info[:2] instead of cutting it from sys.version[:3]
as Python versions >= 3.10 have more than 3 characters for their version
string. Bump minimum Python version to 2.1 because the new
ax_python_devel specifies this.

Will go into 2.3.4.

In T5744#153233, @alexnadtoka wrote:

And --keyserver-options check-cert is removed from new gpg versions (((

@ikloecker yes sorry ok

@bernard Right sorry. I have sent request to mailing lists

@alexnadtoka, please stop adding the same information to two different issues. Let's use T5744: Issue with connecting to GPG server for any further comments.

@alexnadtoka wrote:

both versions had issues(( and send two requests to RU and EN comunity . No answer for two days already

@bernhard yeah thank you. both versions had issues(( and send two requests to RU and EN comunity . No answer for two days already
The log clearlys says certificate is expired(( but it is not at least for keyserver... May be it is reffering to gpg key... I dont know... but it is not expired either. Probably I am missing something. Will try to contact community again.

Here is log in english

@alexnadtoka When using Gpg4win-4.0.0 or 3.3.16 with an updated GnuPG the validation of dirmngr works fine with the Let's encrypt certificates again. If you have one of these versions, and you still have problems, you need to be more specific about which connection you are referring to.
Maybe it is best to ask on one of community channels (e.g. the gnupg-users mailinglist, see https://gnupg.org/documentation/mailing-lists.html )

The odds for this case are infinitesimal so this should not have high priority. I consider this only a code-is-as-specified thing.

Do you have a ballpark figure for the install base (not including variants such as debian with modified defaults)? That might help us decide what counts as "overloading".

The problem is just that there are not that much keyservers left and thus I added those running by large organisations. I really don't want to overload your servers. I would also trust nlnet more than canoncial which is why I started with them.
Its all a mess. Maybe no keyserver should be the default.

And --keyserver-options check-cert is removed from new gpg versions (((

@werner can you show me tutorial for proper bug submit? I think it is a bug and gpg client on Windows does not support valid LetsEncrypt certificates on keyserver. It does not work with any keys server . Tested few public keyservers as well. ((

(q)gpgme now tries to detect a failed import caused by a bad passphrase and emits a bad passphrase error in this case. Kleopatra then shows a "Bad passphrase" error instead of an "Invalid object" error.

We decided to notify the user if the keyserver doesn't return fingerprints. The fingerprints are needed by Kleopatra as unique identifier for keys. Trying to make key lookup work without fingerprints isn't useful.

Please see https://gnupg.org