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.

If a certificate is in more than one group, this will not work...

It seems to me there are two separate concerns here:

I have now backported the missing error reporting to gnupg 2.2 (rG6f0066db2c87: gpg: Report an error for receiving key from agent.). Please retest once gpg 2.2.41 is included in GnuPG (VS-) Desktop 3.x.

Pushed the change, although it is not enabled yet (since the feature will be only available by newer libgcrypt, 1.11).

Pushed.

Pushed to master.