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.

The change rG60963d98cfd8: gpg: Detect already compressed data also when using a pipe. for T6332 introduce IOBUF_IOCTL_PEEK.

Implemented in rA9110945ce625: Implement timeout in assuan_sock_connect_byname..

Actually, it's not 'connect' system call, but 'CONNECT' request which matters. The use of SOCKS in libassuan is that it always connects to SOCKS server at localhost.
So, other than the special case of erroneous configuration of TOR, introducing timeout handling to the initial connection to the SOCKS server makes less sense.

If it were the case, I think that graceful shutdown of the system would need to terminate the client of scdaemon at first.

The root cause might be that the "DEVINFO --watch" command causes ...

I also experienced hang on shutdown with GPG 2.4.1 and bisecting reveals that the first bad commit is rG2ccbcfec121f.

@werner I tested by switch back to GnuPG 2.4.1 (I downgraded to 2.4.0 before to temporary work around issue), adding compress-level 0 to gpg.conf file. It's not working. The problem still exist.

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

And please add a tooltip for "Certify for everyone to see (exportable)", all other options there have one.
Suggestion for the text:

To sort out LTO warning someone needs to make the decision which one routines declarations are correct (those in header files or those in .c files).

As I mention LTO warnings are most important.
Just retested 2.4.1 and I still see LTO warnings which still not been sorted out and those warnings are not false positives.

[tkloczko@pers-jacek build]$ rpmbuild -ba --with check --with failing_tests gnupg2.spec --quiet 2>&1 | grep -- \\[-W | sed 's/.*\[//; s/\]//' | sort | uniq -c | sort -nr
     28 -Wunused-result
     22 -Wlto-type-mismatch
      4 -Wenum-int-mismatch

<details>

Just checked 2.4.1 and looks like now everything is OK.

If you experience build problems on macOS see T6442

Instead of using gpg --quick-set-expire with the * wildcard for the subkeys to update, the subkeys to update are now listed explicitly. This way the last three options from my comment could be implemented, i.e.

• Subkeys without explicit expiration are not updated. Note: This doesn't work for already expired subkeys because gpgme has no way to know whether an expired subkey has an explicit expiration set because gpg --list-colon always prints an expiration date for subkeys of expired keys.
• Not yet expired subkeys with explicit expiration are updated.
• Expired subkeys which expired at the same time (+/- 10 seconds) as the primary key are updated.
• All other expired subkeys are not updated.

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 had two arguments about using gpg_op_createkey, first it was only available on "recent" gnupg versions. That is obsolete now.
Secondly it required you to add each subkey one after another. With rentering the passphasre. This could lead to error behaviors are was just confusing. But otherwise I am all for it. But I think changing this now is a bit too invasive.

works

Starting to understand KIO architecture a bit better. We can easily add more protocols if we want to. For now I have just added the file plugin. I tested with moving.

Adding @werner @aheinecke to get their feedback especially on the options at the end of the previous comment.

@Angel thanks for the valuable feedback

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.

Option #1 is good from a descriptional POV, but in most cases both the main key and the subkeys will be expired, so it would end up not updating any subkey.

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.

I see the point of use of int.
For backward compatibility, the semantics of 0 should remain as default timeout (let kernel decide == 120 sec, usually), -1 would be meaning immediately (only success when local).

Thank you for your report. Good catch.

The fix is in 2.4.1.
It's not perfect fix, but it catches the problem when it's not encrypted secret key.

The code for the file Job etc. is definetly in there. I think it somehow tries to intospect supported protocols maybe even through dbus and this fails then. My current expectation is that we need to identify where this happens and then to hardcode some supported jobs / workers etc.