Will be in 2.4.2

Well okay, then I have no workaround. However, I won't consider this a bug because BEGIN_ENCRYPTION marks the start of the actual encryption process but not when it starts to read input data.

I have not yet experienced that although I am using Gnus with encrypted mail all the time. My guess is that this is due to the improved compressed input detection in gpg. You might be able to work around it by adding compress-level 0 to gpg.conf

If you experience build problems on macOS see T6442

There are pros and cons for both key generation versions. I can't remember whether or why I decided that --quick-gen-key should behave different. Maybe because the creation of the subkey was added a bit later or because a new internal API is used here.

I will review the issue. A likely outcome will be to follow your suggestion but to add an option for the old behaviour to avoid further security discussions.

The user tried to sneak in an ad link and he has thus been banned. Here is his probably AI generated comment for documentation:

That comment was used to sneak in an ad. For documentation here is the comment w/o the link:
The changes made to the code have improved the workflow when verifying detached signature [redacted] without a corresponding signed file from Kleopatra's UI, which should make the process more intuitive for users. It is possible that users who experienced this issue in the past may express their satisfaction with the fix in the comments, while others may provide feedback on the usability of the updated workflow.

I don't see a reason backing off the original commit. A fix for macOS is now available (rCfa21ddc158b5) and will be in the next release. No reason for other changes.

Closing. A small change in Kleopatra (T6472) should help to avoid using this hack in common cases.

Why can't we keep the signed int? Do we ever need such a long timeout. We could for example define -1 as use default timeout.

This has been fixed for gnupg24 and gpg4win.

!ebo: Did you set a log-file into gpg.conf or common.conf ?

That is basically the key signing party scheme we developed at the keyserver convention in Utrecht in 2000. Sometimes also known as Sassaman or over-the-lunch protocol. Gnupg used to come with a tool named ring-a-party which did the paperwork. However, experience has shown that it is too hard to explain and get right - even to key signing party geeks.

Funny enough that Python seems not to allow to set the permission with open. Low priority because a proper umask must anyway be used on a multi-user system.

There is still a buglet because in some modes the weak key error can be swallowed by other errors. A fix would be something like:

I wonder why github did not automatically closed this pull request - after all exact that patch was commited.

Okay, that was easy to check.

Not easy to fix because gpg --card-edit/-status has some support form other cards. Eventually these commands will be replaced by gpg-card. In the meantime we can use this hack:

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

To replicate the problem it is best to use Windows. Should be solved with my commit. Note that the bug is specific to 2.4 dues to irts multi-card and app support. There was no problem on 2.2.

The actual error is in gpgme. CreateProcess is called with "gpgtar" but "gpgtar.exe" must be used.
This has been fixed with commit rM0c29119e061c. The reason why we didn't noticed the real cause of the problem is that the CreateProcess error shows up in the gpgme-w32spawn helper which has no good way for returning errors.

In T6451#169608, @gniibe wrote:

Reading the commit rC5beadf201312: Add gcry_cipher_ctl command to allow weak keys in testing use-cases,
The test code in basic.c assumes that it is an application responsibility to confirm&ignore GPG_ERR_WEAK_KEY error when using GCRYCTL_SET_ALLOW_WEAK_KEY.