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.

Somehow I was waiting for such a comment ;-) Sure you are right and we will fix the README eventually.

See T6310 and the release note update at T6303.

Sorry, I can't replicate this.

This bug is CVE-2022-47629

This does not look like a problem in GnuPG/gpg4win because gnupg implements the ssh-agent protocol and not the ssh server or client functionality. ssh tells sshd whether it shall allocate a PTY (Pseudo TTY). I don't use ssh with github but it is likely that you may only run commands (which don't require a PTY). Usually you would invoke a "git" command cia ssh.

I pushed a similar fix last week: rE885a287a57cf060b4c
and gnupg has a hack to fix it for oler libgpg-error versions.

I meant bypass the gpgme engine and call gpgsm directly. Maybe using gpgme's spawn engine. But I am not sure whether this is really a good idea. If we can find a way to pass multiple filenames to gpgsm --server that would be better. But requires updates to gpgsm.

With 100 concurrently running gpgsm processes they all try to get the lock for the keyring. And they need to do this several times and often also for the same certificate (fetched from an external resource to complete the chain). Not good. It might be easier to bypass the gpgsm and run gpgsm directly instead of adding a feature to gpgsm to directly import from many files.

Note that in-source-tree builds are broken - see T6313

Unfortunately this breaks in-source-tree builds - see T6313

You should do it for all software ;-).