you also use the CPU cache size on GNU/Linux. Is it important to have that information on MS-Windows?

I don't like it either but the browser vendors don't like SRV records.

Not in the way it is used by gpg. See T5880

I still think that redirecting to another catch-all domain is contrary to the original goal and weakens the security model. We need to see what we can do about this.

The attached patch implements getting the number of processors on MS-Windows.

Thank you, works now on Windows with openpgpkey.sanka-gmbh.de

SOCKET handle is UINT_PTR on Windows. It is u_int on original MinGW, it is UINT_PTR (and unsinged __int64_t) on MinGW-W64.

Independently of that, it seems that gpg4win doesn't work with at least one widely deployed webserver in its default configuration, specifically Caddy, so this fix is well appreciated.

I still think that redirecting to another catch-all domain is contrary to the original goal and weakens the security model. We need to see what we can do about this.

Not in the way it is used by gpg. See T5880

Oof. That hinges on the certificate, guess we'll need to renew the bunch of them. I reconfigured, might take a while for all pages but ciphers should now be:

The ECDHE_ECDSA suites are not yet implemented in ntbtls and thus we can't agree on a common cipher suite. Will be solved in the next Windows version.

In the above test, I was using
Windows: 2.3.4
Debian: 2.2.12

I captured some logs server-side, and I do see this error:

Are you using 2.3.4 also on Windows?

I have the same error when using wkd.keys.openpgp.org with a CNAME DNS entry. The error occurs with Windows 10, 11 and Server 2019 (only the most recent versions tested). With Debian it works fine.

see rC67b36154f88e for master.

Will add it. The reason I added Brainpool was due to a question on the performacne between Brainpool and other NIST.

Last part is applied. Let me consider how to solve, for other parts.

Original MinGW and MinGW-w64 handle differently.
For MinGW-w64 on 64-bit machine, pid_t is 64-bit integer.
For original MinGW on 64-bit machine, pid_t is 32-bit integer.

Not applying the change to GnuPG 2.2, users can use GnuPG 2.3 for that.

The patch I proposed was partial one, not fully solved the problem of socket resource leak on Windows.

Done in master to be 1.11 for server side rC754ad5815b5b: random: Remove use of experimental random daemon.

Done in 1.10.1.

Summary of abidiff for libgpgmepp:

Functions changes summary: 6 Removed (20 filtered out), 0 Changed, 0 Added functions
Variables changes summary: 2 Removed, 0 Changed, 0 Added variables
Function symbols changes summary: 0 Removed, 0 Added function symbol not referenced by debug info
Variable symbols changes summary: 12 Removed, 0 Added variable symbols not referenced by debug info

Good idea. Thanks. Goes onto 2.3 and 2.2

Ingo, it would be great if you could work on that. For me the most intresting use case is to fully revoke a key because it has been superseeded.

I'm also seeing this, but that's probably due to me using "focus follows mouse" and the pinentry being a different application. When the pinentry goes away the window manager gives focus to the window below the mouse which very often isn't Kleopatra when I have been testing keyboard navigation.

I wonder if we even should change gpgme to do a key refresh when you call it in VALIDATE mode and online? Semantically this makes sense to me as this is where CRL checks for S/MIME are done. But from a conserviative standpoint this could be considered an API change if the API then does something differently and that even does a network connection. So while I consider it I don't think this is a very good idea.

This occurs on Windows. But if a raise is really missing, it might also occur with other window managers.

On which OS resp. with which window manager does this problem occur?

In T5886#156407, @TonyBarganski wrote:

2. As things stand right now, someone with a Public key created on gpg version 2.3 on a macOS cannot privately communicate with someone using a Linux server, news group or Linux Desktop.

I read OpenSSL implementation.
It does NOT implement backtracking.
In openssl/crypto/x509/x509_vfy.c, it has a function find_issuer which does:

• exclude a issuer when it's already in ctx->chain (can avoid recursion forever)
• prefer the first non-expired one, else take the most recently expired one.