Indeed, this is not implemented. AFAIK, this feature was introduced by PGP 2 to support BBS systems. I would suggest that you use binary messages and implement the chunking at the application level.

I'll add new error codes to gpgrt

You could configure gpgme with

Any volunteers to write a manual? ;-)

No, it would break the verification of too many signatures.

After diligently reading the code I realized that this bug has long been fixed. For reference here is the patch I wrote to extend dirmngr_ldap during my tests:

The flag has been implemented in 2.4 but as long as this version has no approval it does not make sense to do anything more. Let's re-open this task if we have a real request for this.

I added a remark to the print function. Thanks for the suggestion.

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.