We will keep the 1.24 branch for bug fixing. Do you really have a problem with gpgme 2.0? Ist that due to factoring out the c++ and qt bindings? That was actually a long standing request from the KDE community so that they can use their cmake stuff.

I updated the version database. We now have entries for "gpg4win", "gpd", and "vsd"

I see, I had rfc2440 in mind which says:

By convention, it includes  an RFC 822 mail name, but there are no restrictions on its content.

thus 4880 refined it a bit. But in practice it is not the same because it is utf8 and not punycode or whatever. let's close this bug because they way it is used will work with all mail clients.

Let's have a look at the spec (rfc2822 3.4):

address         =       mailbox / group

We should also add a check that INDATALEN is > 15 to make the function robust against bad args.

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.