Thanks for the report. Fix is easy. I only wonder why you want to use a weak DES key.

On Windows we always use --status-fd=1 but with gpg it is not a problem because we use a differenrt fd for output.

Unfortunately I can't replicate that with my Yubikey on 2.4.1. Tried several variant and with and without keyboxd. My Yubikey has PIV disabled but I doubt that this is the problem.

Actually Linux already returns ENOSYS on older kernels where there is no getrandom libc call. Thus returning ENOSYS if we don't have the libc version of that syscall (i.e. getrandom) in FIPS mode seems to be the Right Thing to do. My whole comment was about fips mode - it does not make much sense to enable FIPS mode if the system is not appropriate for it.

What about

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.