Release quite some time ago.

The compression check currently detects bzip2, gzip, zip, pkzip, and PDF. This also covers common document formats like odt and docx. We may add some more detection in the future. However, for large files you usually know their type and thus you better use "-z0" for already compressed data or "-z-1" if you want to force compression (may be for PDFs which often can be a shrinked to 80% or so).

Sorry, but we can't check all parameters. Why only check that one and not the others or invalid values for ctx. You may do such checks in an interactive environment but not for a general library.

This can be easily tested using

No more logs. My understaning is that the pypi ownershipof the project has been transferred to @bernhard

Given that there is now also a restriction for rsa2048 in de-vs mode, can you please also restrict all non-brainpool curves?

Backported the needed stuff:

These are 2.4 features ...

no-tty and charset are anyway obsolete and passed only for older gpg versions. The other things should have useful defaults in gpg - in particular these defaults are taken from the same envvar as gpgme does. See send_pinentry_environment.

See also T6329

See T6340 in case of build problems.

Will not be fixed because the only change is intentionally the export target for a regression test suite. The other fix is for the old FIPS RNG which is not used at all.

It turned out that this does not make much sense.

Actually, the entire systemd based launching is deprecated and thus the logged warning is on purpose.

Nope - too long for checking and introduces line wraps. Those who are not able to check digital signatures are also not able to properly handle checksum verification. On some platforms you don't even have a sha256sum tool. And they need to verify the mails first anyway. Note that for internal purposes we use sha256sum for years.

We can simply change the arg type from number to string and use a value like 3072/20240101

What I mean is that our socket emulation is encapsulated in libgcrypt and details should not be visible to the caller. Further libassuan and kleopatra might be build against different libc versions and thus the used structures might also differ.

I do not consider the whole PyPi thing a secure solution and thus we do not want to engage us there. However, if you need small patches to GPGME, please go ahead post them to the ML or upload them here.

The question is why Kleopatra does not use assuan_sock_set_sockaddr_un as we do in GnuPG. See for example
https://dev.gnupg.org/source/gnupg/browse/master/kbx/keyboxd.c$1124 - was this a workaround back when we had no support for Unicode? assuan_sock_set_sockaddr_un and assuan_sock_get_nonce work together and their internal workings should be opaque to the caller.