@ikloecker thanks for your reply.

I don't see a point in trying to make the fancy curses pinentry work on small terminals.

Fixed in master. I rechecked that bulk implementation passes tests with qemu-ppc64le.

Looks like that line went missing in third/final version of AES-GCM patch at https://dev.gnupg.org/T5700

Added the HWF_PPC_ARCH_3_10 list in ppc_features[] in src/hwf-ppc.c.

There is also the very simple pinentry-tty

As an end user, the --pinentry-mode=loopback flag does exactly what I'd want to resolve this issue. Just to give it more visibility, is there any chance we could try to detect when the user's terminal is too small, and print a message suggesting they use that flag?

I don't see a point in trying to make the fancy curses pinentry work on small terminals. People using small terminals can use --pinentry-mode=loopback to get a simple passphrase prompt that works on terminals of any size.

From my point of view it should be fixed by adding line-breaks to make it work on small terminals. It is better to break the formatting, but allow it, instead of bailing out and leaving the user only with the option to use the more complicated interface. This problem could also affect other password entries where a longer information is displayed.

An alternative to password creation in small terminals could be https://www.gnupg.org/documentation/manuals/gnupg/Unattended-GPG-key-generation.html#Unattended-GPG-key-generation

@LRitzdorf it should work if you enter an acceptable passphrase. (I've just tried with 56x51 widthxheight and it worked)

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