It may be better to open a separate issue for the issue in gpg, so that it's not overlooked/forgotten when the issue in gpgtar is fixed.

That is intentional. If we are able to remove a file we do it. Solution for you is easy: gpg .... -o - </dev/null >/dev/null

That is intentional. If we are able to remove a file we do it. Solution for you is easy: gpg .... -o - </dev/null >/dev/null

This looks like the same problem I encountered in Gentoo's Portage. To unlock the binary package signing key, Portage will run the equivalent of gpg --homedir ... --digest-algo ... --local-user ... --output /dev/null /dev/null. If unlocking fails (due to e.g. wrong password), /dev/null is removed: https://bugs.gentoo.org/912808

From my side this can be closed. In Kleopatra we can maybe check for some more MIME types and then use GPGME_ENCRYPT_NO_COMPRESS but that is unreleated.

I am raising this up from the wishlist. Error messages from CRL errors can be so obscure, like we just had in a support call.

Actually it has been fixed for the PBES2 case in 2.2 and 2.4. PBES2 is used with AES128 and AES256. I doubt that there is any value in adding such support for the legacy RC2 and 3DES methods.

This was tested by me against the actual sample and the sample is now part of our internal regression test suite.

with the new gpg.exe you gave me for testing it looks good now:

related to T6528

No. Missing mapping in iobuf.

gpgrt version?

I get a failure status, but a different one.
Seems to be an other issue? But wasn't (ec=112) disk full?
And the disk of the Windows VM must have been running full with that file, before the start there were ~2,6 GB free:

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.

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

rGb1ecc8353ae3 is just what I meant, so that we can recommend such an option in the future as a workaround until a new update becomes available which supports such an extension.

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.

For support reasons I would say that it might make sense to also ignore the extensions from "ignore-cert-extension" when checking CRLs?

I tested this with OpenPGP and 2.4.3-beta19 on Windows. Worked nicely.

And of course we also need to adjust GPGME

We also need PROGRESS lines in gpgsm.

With my fixes I now get this:

Actually two bugs. Easy to test on Unix with a small (e.g. 10MiB partition).

Works in kleopatra; tested with gpg4win-4.2.0-beta339.

Kleopatra test case (similar to gpg):

Fixed in 2.4

Okay, that was easy to check.

@gniibe, will you be so kind an check the provided patches

gpg --edit-key; keytocard; save

work as expected.

works

gpg_encrypt (engine-gpg.c) passes --output - to gpg, i.e. it reads the result of gpg --encrypt from stdout unless I misread this. Not sure, why this seems to work on Windows. The real problem is probably something completely different.

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

The gpgme logs show that gpgtar is called with gpgtar [...] --status-fd 1 [...] --output - [...], i.e. fd 1 is used for status output and for the result output of gpgtar. This cannot work. To me this looks like a flawed implementation of _gpgme_io_pipe() resp. new_fd() in w32-io.c which happily returns 1 as FD on the first call.

I'll add new error codes to gpgrt

works with gpgtar (GnuPG) 2.2.42-beta102, too

I could not reproduce the problem with a self-build gpg4win 4.1.1 (e5dee8abf3045c970f4ba7a0dd7ee5daf08fe7cb). Please list the content of the folder Unterordner.

Only Sign results in the same error as Sign+Encrypt (which was the picture above)