We do this now also for gpg-wks-server. Further gpg-wks-client now sends the current language to the server so that the server can get back to the user with a proper translated text (if configured).

So, what shall we do with vanilla kleopatra, or GPD or VSD? It will be easy to record current versions number in swdb.lst

Alright. We use utf-8 in our template files and switch to QP encoding when needed.

I forgot to mention that gpgrt has an API to compare version numbers in the same way gpgconf and all gnupg components do it; this should be somewhat similar to sort -V

BTW, if you append a beta string the thing works as well. Thus with an development version for 4.4.2 we would get a 'newer' state:

The version file is locally cached and updated from time to time unless that feature is disabled.
An update can be forced using

Re: pipe2: In gpgme_io_pipe we set FD_CLOEXEC only for one end of the pipe. Thus simply using pipe2 would change the behaviour.

This is all done by gpgconf like here:

Yes. If gpgconf could read that version directly from kleopatra it would be even better. Bit in cases of early crashes this might be sub-optimal; thus I will tell gpgconf to get some additional version info from an installed versioninfo.txt file (which gpg4win creates). Thanks.

Please remember to add a comment to the code describing the reason for this renaming.

For vsd on Windows this will be solved due to the use of gnupg-vsd as default homedir. We already tested this with a beta MSI installer

This should compare the gpg4win version number:

If you are experience problems with the test suite on NetBSD, please see T7634

Please re-open if you find other Cygwin related build problems.

You know that Cygwin is not supported but if that is the only place it should not arm to fix it.

Fixed in all branches but there is no potential for exploiting. See also gnupg-devel@ ML.

This should do the trick (master) but have not yet tested it:

The classic NIST P521 pitfall ;-)

FYI: I'd like to get a new release out after these changes.

In T7627#200387, @werner wrote:

We won't apply any fixes to the cpp, QT, or Python language bindings in the 1.24 branch. The Qt branch has been factored out to the gpgmeqt project on request from the KDE folks. And yes, we should add projects (tags) for gpgmepp and gpgmeqt.

Problem noted in T7166

Noet that one file is missing in the released tarball; when building for RISC-V please see T7647#201164

Patch applied.

(The commits had a wrong bug it in their message)

It might be useful to have samples of compressed keys:

No, we can't do much about this. It has always been easy to create compression bombs and the more relevant thing here is compressed signed or encrypted data. Or just compressed mails. The patch by @DemiMarie is way to complicated for what it wants to achieve and actually breaks existing use cases. For example Poppler uses GnuPG comment packets to lower its own attack surface by leaving all OpenPGP handling to gpg. The patch (or at least the version we noticed in Fedora and Debian) entirely breaks this use.

Also pushed to 1.11

Way too complicate and thus has a high risk of regression,