Partly done for 2.4. The cram-octet-string stuff is missing, though.

This has long been fixed in 2.4. Given that Libgcrypt has support for PBKDF2 we can back port this.

FWIW, gpg shows the actual cipher and encryption mode with -v. For example

s/CBC/CFB+MDC/

Can you please test by adding --exit-on-status-write-error to the gpg invocation by gpgtar?

I don't think this is the right choice: Un Unix we have file descriptors which ar an (int) and on Windows we use (HANDLE) which is a 32 bit integer. See my comment in T6551 regarding values for HANDLE.

Just to clarify this change for readers not accustomed to Windows internals: This function was used to translate the file descriptor as passed to gpg (which is a HANDLE) to the libc file descriptor as used by stdio. Obviously we won't anymore work with stdio file descriptors in the future but use the Windows32 API (ReadFile et al). libc fds 0,1,2 are handled in a special way on Windows.

Due to the double fork in gpgme we won't get the exit code which gpgtar emits. Possible actions in a signal handler are also limited; in particular we can't use stdio or estream. The only option to print a status line would we by using write directly. However, this might mess with the libassuan buffering. Thus, it is not a good idea to pkill gpgtar. Same is true for gpg and gpgsm.

See for T6545 for a new request to support IDP.

We had one request to support this back in 2017 but it was closed because the respective CA stopped using this extension. See T2039.

See T4168 and rMecfa48fffa9 for the reason why we need this conf directory. Thus (1) is not an option.

Nah, the description for that extension is pretty strict and I won't feel comfortable to just ignore it. BTW there is also T6398 (nameConstraints) which needs support. But for debugging a ignore extension makes sense.

Use Kleopatra which constructs the DN for you ;-).

I have now disabled the rewriting in the 2.4 branch. Those who want to keep the old behaviour may add