Fixed with: 8e258f77114ce0474a2bb6aa1314385e2fb68e15

In T6330#170382, @ebo wrote:

[...] 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.

With the recent commit the old workaround works reliably again.

works

Thank you, your suggestion inspired me to experiment a bit further and I found the problem - I needed in fact to delete the line from my ssh config, no idea why:

Match host * exec "gpg-connect-agent UPDATESTARTUPTTY /bye"

Now I update startup tty only on terminal start and it seems to be working. Still a bit strange.

This is a standard C pattern to declare that one is not interested in the return value. In this case a return value won't help us because we can't log that anyway because we are in a signal handler.

On a terminal, please invoke:
$ gpg-connect-agent UPDATESTARTUPTTY /bye

My use case is using Wine, like this:

• having different bindir (/usr/local/i686-w64-mingw32 and /usr/local/x86_64-w64-mingw32)
• but I was too lazy to have different configurations for 32-bit and 64-bit, but to have shared configuration with
  • PATH adding both of /usr/local/i686-w64-mingw32 and /usr/local/x86_64-w64-mingw32

Pushed to GnuPG master. Let us test. For my machine of Debian GNU/Linux, Wine emulation (Windows 32-bit, Windows 64-bit), make check goes all well.
After confirming the implementation, I'd like to put it into gpgrt.

You are right, it is a bad habit not to check this. Thanks for your patch.

We need the 64 bit version for the GpgOL because there are 32 and 64 bit versions of outlook. Thus we also need a 64 bit gpgme and in turn a 64 bit libassuan and libgpg-error. I can't remember why we don't append the 6 to the gpgme dll, though.

Anyway, thanks for fixing this.

It does work indeed!

Guessing that it works now.

Meanwhile fixed.

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