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.

we have a similar problem in our organization. We're using Outlook from Office 365. For two weeks now we have set a GPO for Outlook to prefer plain text messages like in @kimmoal's organization environment.
This causes the same problem: We are getting blank emails when they are encrypted or signed.

When we will find reproducible test case, please reopen.

Use a gpg 2.3 version:

Hi Werner
.
Firstly, let me say how much I appreciate the work you and others do at OpenPG.org! Really.

• No we can't because current GnuPG 2.2 versions are able to decrypt such AEAD data.

See also T5537 and commit rG7d1215cb9cba2 for 2.2.

There is actually a much easier fix here. Thanks for pointing out the problem. For histroical reasons we have several places where we create the homedir.

1. So, firstly, can we get an error message that states something to that effect AND can also be displayed by Mutt?

Confirmed to work, thanks!

Thank you. Applied.

Implemented.

Thank you for the error output.