Kleopatra is a 64 bit application, right? For GnuPG we are working on 64 bit support for Windows. This is planned for 2.6. problems are how to represent sockets, file descriptors, streams and so on. Regarding the time interface, we should have everything ready in the GPGME<->GnuPG interface. In GPGME we need to check that we don't use int instead of time_t, though. When that has been done/fixed we could use a 64 bit gpgme and kleopatra along with the 32 but gnupg. Might be easier for approval reasons.

It turned out that we need to fix this for use by Kleopatra on Windows.

That is intentional. If we are able to remove a file we do it. Solution for you is easy: gpg .... -o - </dev/null >/dev/null

Needs to be checked for 2.4 - no backport to 2.2, though.

Needs to be checked again with stable. No backport to 2..2, though.

Won't be backported to 2.2 once we got something in 2.4.

We should not backport this to 2.2; better update to the current stable version (2.4)

[For bug reports please don't refer to some other site - at least a brief but useful description should always be included]

Sorry, I only now noticed that you used the --export-secret-ssh-key. Unfortunately commit
rGafe5fcda52e88438c7a7278117b2e03f510a9c1c states in the comment:
"Due to time constraints the code is not yet ready." Let's turn this into a feature request.

I mostly used ed25519 keys and thus I do the avove command pretty often without problems. Can you please add

-v --debug lookup

to the command line show us the log (send privately to my standard mail address (wk@gnu...) if you feel that data is too sensitive for the public).

We have no dedicated error to tell that the verification failed due to an non-compliant algorithm. Thus we return invalid public key algorithms as best approximation. You could use --override-compliance-check, though. We discussed things thing once at the Gutenbergweg.

The data is indeed corrupt. Check with the sender of that key.
IF you look at the data you will soon notice that one line is longer than the others.

Please ask on the gnupg mailing list for support. In case that turns out to be a real bug, please re-open this bug.

Here is an example from my QES cert:

That does not mean that this is a good idea. And well, I heard that Poppler does not have a stable API.

Don't do that. The key usage extensions rarely useful. This is the usual X.509 DbC (design by commitee) mess. See for example https://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt . Let's not try to follow this path.

Good idea.

Use the is_qualified flag to figure out QES certificates. This is more than just a capability flag.

NonRepudiation is not a well defined term. It is used by X.509 but often used similar to a digital signature. Thus this does not make sense. The is_qualified flag is what we need for QeS and it seems we already got this in gpgme.

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.