We are hoping to have at least a beta release soon with gcrypt 1.9 that we can put in a Gpg4win-4 beta.

This works with the message class changing. We still need to do it for OpenPGP, too.

The problem is not with creation, that works. The problem is also not with files contained in the archive, they also work. The problem is the archive name. And that also seems to be correct in the way gpgtar extracts it as gpgtar successfully extracts the archive, but the created folder name has the broken character.

I think the main work of listed translation update has been completed, and other minor problems will be corrected in the future patch.

I can't replicate this on the command line. Anyway option -T is only valid with --create. Further the archive format is specified to carry utf8 filenames; thus --utf8-strings won't have an effect on --extract. Are you sure that Kleopatra runs

gpgtar --create --utf-strings -T -

and you pass utf-8 encoded filenames on stdin?

This has been resolved with rOb05416e7bc41

If you encounter this error message when running gpgconf --list-options gpg:

gpgconf: Option gpgconf-gpg.conf, needed by backend GnuPG, is not absolute

please simply create an empty file /etc/gnupg/gpg.conf or wherever your global configuration files are expected ("gpgconf --list-dirs sysconfdir" shows it). Bug fixed with commit rG9f37d3e6f307a9

This can be closed now that we have the system wide gnupg configuration.

Thanks for your answers. If you see another problem with kleopatra, please test the latest Kleopatra version which we will release the next days.

The code has been reworked to also support the updated schema which also stores the fingerprints and a parsed down mail address. See gnupg/doc/ldap/ . These changes are in master and 2.2.26. Sorry for taking so long to fix that.

I agree to the sexp change - but it should not be backported to 1.8

For printing SEXP, it would be good to have this change:

rG47c1c329ed82: agent,ecc: Use of opaque MPI for ECC, fixup 'd'. does the fixup when reading keys.

I describe about rC6f8b1d4cb798: ecc: Consistently handle parameters as unsigned value..

Reading compressed point (in keys) is supported (except for NIST P-224). When curve point is represented in compressed format, it is correctly interpreted now. So, for example, I think that with 1.9.0, gpgsm can handle certificate which uses compressed format in its curve point representation.

1. I created another handful of key pairs and tested around. However, I could not recreate the problem now. I can store the secret key in Kleopatra, but the file differs from the backup key. It seems to be a stub indeed. And even if I want to perform an operation directly in Kleopatra, the smartcard is requested.

Yes, bug is also in 1.8 branch.

Why do you think you can still export more than a stub key?

The listing shows that the private keys are stored on a card ("sec>", "ssb>"). Why do you think you can still export more than a stub key? If I export a test key (just the primary key in this case) and run "gpg --show-keys" on the exported file I get the expected "sec>" marker. Looking with --list-packets at it we get:

The exact commands given and the output. Adding -v is always helpful.

Hi, I'm the user that reported this bug.

do_sign() calls find_fid_by_keyref() which does a switch_application(). So, I think the SigG application should already be active. But, yes, please have a look at it.

I'm also getting this same error with GPG4Win 3.1.14.