Can you please share the expected result with us? Note that Libgcrypt strips leading zeroes except when it is required to keep the value positive.

I pushed your chnages and removed a lot more code.
See: rPabbecc67

This has been solved loooong ago.

@jukivili was so kind and does the mirroring now.

Actually this is about improving an error message.

Thanks for your follwup. Let me remark that it is sufficient to stop all gnupg processes (pkill gpg-agent) and then rename the ~/.gnupg to .gnupg-save-NNNN. This way you have a backup and gpg will create a new ~/.gnupg.

FWIW, some cards don't have PUKs but two PINs which are able to unblock reciprocal.

OCB mode (i.e. packet 20) is only used if the keys announce it. Thus only after moving a (private) key from GnuPG to a non-GnuPG compatible implementation you will run into this problem. The compatibility options won't override the preference system.

We need to extend dirmngr_ldap.c to take a list of attributes to return. We already have the --multi option which returns all attributes for latter filtering by the caller but the specified attr is also used and thus dirmngr's start_cacert_fetch_ldap() retruns only the requested caCertificate.

Things for 2.4 are all done.

For 2.2 we will for now only implement the encryption.

@gniibe: Would you mind to look at this?

README and INSTALL now suggest to to use a build directory.

Error checking of the parameter file is usually enhanced when adding new features. Keeping this task open for this specific request does not make sense,

Turned out to be a bit come complicated. I hope that I did not break any of the other pinentries:
rP8ab1682e80a2b4185ee9ef66cbb44340245966fc

This header was introduced close to 20 years ago. I agree that it does not make any sense - it might be a left-over from an old Hurd version. We can entirely remove it because string.h is already included and we also don't use memory.h anywhere in gnupg proper.

Yes, --export creates the OpenPGP specified format.

We stopped maintaining GPA in favor of Kleopatra.

Do you mean the pubring.gpg format or the on-wire OpenPGP format; ie. what gpg --export gives?

Not if there are technical reasons to keep the address. BTW, you solution would not help because the fingerprint of key is personal data in the same way as a mail address.

Will go into 1.19.0

A tool can't make some thing GDPR compliant - this is all about policy and informed choice. There is actually no problem if you allow ppl to decide whether to upload personal information to a public service.

FYI: Quite some more days than a few passed by. I still did not found the time for this, sorry.

That is not a bug but required for backward compatibility. See me/ksba.m4:

I would suggest that with the VSD 3.2 we make --no-user-trustlist the default via the corresponding registry entry and explain how to use --sys-trustlist-name to use a custom trustlist.

Closing this one - see T6378

Fixed in 2.2 need to check 2.4

Ooops. We do not have the automatic chnage of key type in the WRITEKEY command of scdaemon. This is only done when generating a key.

There is actually a regression wit Yubikeys. The fix for 2.2 is in T5100: rG08cc34911470 - for 2.4 I need to check

Ignoring the error seems to be the best choice. I also think that --force should not overwrite a shadow key file. It seems safer to explicitly delete the key first. A --force option for READKEY does not sound right.