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.

it still shows the no certificate or invalid encoded error message:

Packet 20 is the new AEAD packet which GnuPG 2.3 can generate and does generate if all recipients have new keys generated with such a versions. However, the version of gpg you use now does not support AEAD and thus fails.

Since decryption is broken, I'm raising the priority level of this ticket.
It would be wonderful if someone can take a more detailed look into this problem. :)

Indeed, different versions of MinGW use different symbols to guard the declaration, and using those symbols in not future-proof enough, IME.
Removing the declaration is definitely the best solution.

I gave it a try. It works now, but it still shows the no certificate or invalid encoded error message:

And I move functions from pinentry.c to pinentry-curses.c, so that pinentry-w32.exe can be build with no libiconv (which is actually not used).

Thank you for your report.

Merged into T5804.

Thank you. Confirmed.

Thank you for the reproducible test case. Confirmed.

Pushed the change removing the definition.

GetNativeSystemInfo. Would you like me to submit a patch that used that in jent_ncpu?

Sorry, HOME and ~/ are not standard on Windows and applying your patch may break existing installations.

Yes, I see the problem:

In T5889#156302, @gniibe wrote:

Considering again, I think that just removing the definition of the struct timespec in npth.h is the best approach, given the situation, it's been there for MINGW64 and it's now in original MinGW.

Thank you. Confirmed.

Thank you.

Considering again, I think that just removing the definition of the struct timespec in npth.h is the best approach, given the situation, it's been there for MINGW64 and it's now in original MinGW.

Thank you. I understand the situation by looking at mingwrt-5.4.2-mingw32-src.tar.xz.