We have new box meanwhile.

We do manual approvals.

it would break the verification of too many signatures.

backported to 2.2

@aheinecke As I wrote "the thresholds should be shared by all applications". Therefore (and because the code is in libkleo), using kleopatrarc wasn't an option. Or is the question why I didn't use libkleopatrarc? One advantage of using a separate file is that watching for relevant changes by other applications is much easier resp. that one doesn't get change notifications for unrelated settings.

Mmh, why did this go into its own rc file. I guess its because its in libkleo and not in Kleo itself. I have to check how this works with my registry code. I doubt that this will work out of the box but its important for us that our settings can be set through the windows registry.

Yes, kleo-expirycheckerrc is optional. I'm not sure where the config files live on Windows. It's used by libkleo, so it could also be %APPDATA%/libkleo. The setting in the appearance tab is stored in kleopatrarc. (I thought it makes sense to have the warning configured per application, but the thresholds should be shared by all applications.)

works, no KIO error. Gpg4win-4.1.1-beta317

Works. The only drawback is: for the message to be displayed in the "for others" part of the encryption dialog you have to click in the next line before it is displayed.
If you click on sign/encrypt directly, you won't see the warning. At least if you select the recipient by starting to type and the selecting from the dropdown.

And when I set the validity to never expire (works) and afterwards set it to a date again, the date is now only set for the main key

The first testcase (with plain testkey Xena) works, both are extended with "change validity". But the expiry day of the subkey is one day later than the date I gave.

Will be in 2.4.2

@werner We could make the wait conditional on (equal epg-gpg-program "gpg"), that is, only when user has GnuPG 1.x.

I think that you both misunderstand my idea a bit. I would like to present it to you at some point over a Video Call or I have to write the proposal out in some longer form.

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