I am not sure. MD5 is still important for some applications, say CRAM-MD5. IIRC, back in 2008 we dis-allowed RMD160 and added separate RMD160 code directly to gpg to fulfill FIPS requirements.

Okay for 1.9.

Note: The commit in master (1.9) is rCe0898d0628789414
and in 1.8 it is rC03e6d6597198ee

The commit which fixes this is rC761a1a0d30

Lowered priority because in reality it is not possible to get a certificate for an arbitrary SigG key on the card. Only accredited CAs may issue certs and they want to keep full control over the key generation.

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?

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

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

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:

Description and translation domain were swapped in 2.2.

On Thu, 7 Jan 2021 09:56, bernhard (Bernhard Reiter) said:

We need to switch to the SigG application. Shall I look at it?

Do we need to backport to 1.8?

Do we really need this for 1.9?

What is the state of this bug? Reading is implemented - do we really need writing (maybe to support certain smartcards)?

It is possible to disable the mlock thingy and if that is not wanted the application should be modified to be suid(root) during Libgcrypt initialization - this is actually how we handle this in GnuPG. Or maybe I don't understand the bug described here. It seems to be more of a support question.

For security and auditing reasons a Libgcrypt SO may not be "unloaded".

gcry_ecc_get_algo_keylen has been added with commit a658c9ccc2c741f40b0b5cdbcd184cfb9a841d17 but documentation is missing.

Please describe exactly what you did so that we can replicate this.

Thanks. I added the OIDs and the missing curves. To go into 1.9

Take care: gpg is also used on platforms with proprietary compilers which don't support -f options. Thus you need to limit this to gcc.

The C++, CL, Javascript and QT Bindings are all written by hand.

It seems you have a pretty good understanding and also test cases at hand. May I ask you to apply the suggested pacthes to master?

Given all the resources we had put on this Python bindings I'd suggest to bite the bullet and replace Swig by handcrafted bindings. More work but we do it for the other bindings as well.

I'd suggest to first try the current version to see whether the bug has been solved.

I think we can close this one, right?

Meanwhile there are simpler ideas and code on how to do only authenticated uploads. Thus lowering the prio.