Finished the step to have cleaner semantics of the implementation by: rA6350f796fdd1: w32: Cleaner semantics for PID and Process handle.
Clarified the fact (1-1).
And as a bonus, when it's "cygwin" mode, peer (client) process ID is now available.

Just let me note that we used to have such an API : the former gcry_ac_ functions. However, it turned out that they were more complicated to use.

FWIW, we should anyway move on Widnows to the gpgrt provided setenv and getenv which are directly based on the W32API. The problem here is only that we have a lot of getenv in out code and need a wrapper. That wrapper would then also need to provide a static string as getenv does. A first step would be to wrap all getenv into gnupg-getenv calls.

Was resolved, see T4457

The warning is now removed immediately, when the input field becomes empty.

In T6473#170571, @ebo wrote:

In T6473#170380, @ebo wrote:

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

Update: This is as designed, see https://dev.gnupg.org/T6473#170299 point one.

This bothers me a bit, as I find it confusing. Werner suggested for subkeys without explicit expiry date we could show in Kleopatra the expiry date of the main key in grey to make it visually obvious that a subkey will expire implicitly when the main key expires.

What do you think?

closing, as setting a password on a key without password works (at least in current gpg4win version). For improvement of the user guidance see T6436.

In T6473#170380, @ebo wrote:

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

Update: This is as designed, see https://dev.gnupg.org/T6473#170299 point one.

Pushed changes for those libraries.

GnuPG is and can't be FIPS-140-3 compliant due to the way it is implemented. We may eventually employ the new hash-and-sign API of Libgcrypt to move into this direction but that has not yet been done. However, this also requires the use of the new indicator API and the, well, a RedHat kernel.

--openpgp means the current OpenPGP standard as implemented by GnuPG. This was important in the first few years of OpenPGP but not anymore today. The option --rfc4880 might be what you want. Please keep also in mind that the preference list declares what a concrete implementation supports and not necessary what's in an RFC.

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.