This is the first report we have on such a problem despite of hundred thousands of users. "Triage" means that we need to look at a report to check its priority.

@werner , why set to "needs triage"? At this moment plugin must be disabled if customer read crypted SMIME E-Mails. So it is critical. disable checkbox "SMIME" will not work correct. Enable "SMIME" will only encrypt as Text, but some E-Mails have HTML.
We have this issue on all systems (Windows 10 and Windows 11)

Please note that: libgcrypt offers ECDH functionality by gcry_pk_encrypt/gcry_pk_decrypt to construct OpenPGP public-key encryption/decryption.

So, this is only for OAEP but not for ECDH? FWIW, GnUPG uses OAEP only for S/MIME.

It's not that needed, in my opinion, as nobody actually uses ECB itself (in real use case). But I understand the point of (possibly, students') benchmarking.

FWIW: I am not anymore very convinced of our tofu code. it leaks too many information because it tracks and stored all signature verification. The model is further way too complicated and the SQL used will eventually lead to a resource problem. Maybe doing Tofu stuff in the frontend is a better idea and get rid of all the history processing which works only for fresh mails and not for data verification.

Yes it is set to tofu+pgp. Is it now possible to change the trust-model on context based?

Thanks for the report, since you are using it on the command line and it works I assume that trust-model is set to tofu+pgp? Because in the Test code there is no context flag for tofu+pgp trust model.

Thanks for the report, since you are using it on the command line and it works I assume that trust-model is set to tofu+pgp? Because in the Test code there is no context flag for tofu+pgp trust model.

I tend to close this as a duplicate.

Cool, I will try it out ASAP. You must have read my mind. Only yesterday evening I ran into problems because the current code in src/Makefile.am to symlink the static libs did not work on my new dev system with a lib64 layout and thought that I needed just a patch like this to fix it properly.

We need to understand the usecase here.

We already detect mail addresses for different purposes and thus it will be easy to enclose them in angle brackets just for comparision.. Almost all trust signatures out there are created by gpg and used to restrict the mail domain. No need for different regexp. See also the comments in the code related to the history.

Here we go:

Applied also in 2.2 branch.

Ah, sorry, I did my own changes before looking T6244#164317

Pushed the changes to 2.2 and master.

Thank you for your report. The issue is handling of static linking in GnuPG.

Renamed bug due it being incorrect to assume this was a bug with libgpg-error. Turns out that a simple patch to g10/Makefile.am in GnuPG 2.2.40 LTS source fixes the linking error. Patch that fixed build for me is attached, which basically puts -lws2_32 in the correct location for builds with the new libgpg-error 1.46 version.

It will be hard to fix this. GnuPG supports exactly one class of regular expressions: something bracketed between "<[^>]+[@.]" and ">$" . Even if the next release of gpg supports more regular expressions, gpg will have to wait years before it can start emitting different regular expressions for scoped tsigs by default.

I recommend, when making a User ID with only an e-mail address, to populate the User IDs by wrapping it in an angle bracket, rather than just leaving the raw e-mail address. It's not just the regexp matcher -- there are other pieces of OpenPGP software that won't recognize a raw e-mail address in a user ID as an e-mail address. It also makes it easy to distinguish such a User ID from a User ID that is not at all an e-mail address.

Fixed Gpg4win version: https://lists.wald.intevation.org/pipermail/gpg4win-announce/2022/000098.html

As usual see https://gnupg.org/download for links to the latest packages. For Gpg4win see https://gpg4win.org

Thank you for your report. IIUC, your log is the build log of GnuPG 2.2, so, I put the tag "gnupg (gpg22)".

I believe https://dev.gnupg.org/T6239 also applies here. It would be great if the fix could be backported.

This also affects 2.2.40. Will the fix be backported there? Thanks.