Our sales team gets the support calls and they have to explain that really often.

FWIW, we also need this for Windows. ppl often ask what to do after they installed VSD because they can't find a program. Thus a menu ala Kontact is the way to go. It would be linked directly from a GnUPG Desktop entry from Windows. We can even keep the old Kleopatra becuase it does not harm. Whether the "menu" is a container window or a detached windows can be decided by the user, like GIMP and other tools do this.

I don't have an idea where to start looking here.

Okay, will go into the next revision. Thanks.

The patch to the specs would be this:

        The three data items hashed for document signatures need to
-       mirror the values of the Literal Data packet.  For detached
-       and cleartext signatures 6 zero bytes are hashed instead.
+       mirror the values of the Literal Data packet.  Note that for a
+       detached signatures this means to hash 6 0x00 octets and for a
+       cleartext signature this means to hash a 't' followed by 5 0x00
+       octets.

Regading your first point: From gnupg (2.4) sign.c:hash_sigversion_to_magic

Phew! This bug has been with us for more than 20 years unless gpg's behaviour has changed only later.

I would change the error to GPG_ERR_BAD_DATA .

I agree.

The relevant commit is rGc03ba92576e34f791430ab1c68814ff16c81407b

We had to add the parameters because some keys don't use the default paramters PGP and gpg have used since the introduction of ECC 12 years ago. So yes, we could fallback to the standard parameters but it would bet better if Kleopatra could extract them from the public key (maybe via a GPGME helper).

That assumes that libtool won't change substantially as it did several times in the past and broke our cross compiling stuff. But as long as we keep the ltmain.sh in our repo and tarball the patch is okay because it better documents the chnages.

I can't find a missing forward port; need to debug this issue with gpg4win 4.2.0

I wonder why you mention Visual Studio and Cygwin? Either it is Cygwin or a native Windows build.

See T6585 for the 1.21.0 release

Am I correct that the reason for the speed up is that it can use a second CPU's engine. If there is a real performance improvement here, we should add this for example using a --compatibility-flag. This way we can gather experience and eventually make it the default. The compatibility flags won't introduce an API incompatibility.

Also done for 2.2.

Actually it has been fixed for the PBES2 case in 2.2 and 2.4. PBES2 is used with AES128 and AES256. I doubt that there is any value in adding such support for the legacy RC2 and 3DES methods.

Same for the backport to 2.2 which uses the same test suite.

This has long been implemented due to the backport of the P12 parser and the recent rewrite of it.

We should make building with LDAP mandatory.

This was tested by me against the actual sample and the sample is now part of our internal regression test suite.

No. Missing mapping in iobuf.