The latter. Detecting mail addresses with regexp is anyway a kludge and we have more stringent code to detect mail addresses in a user-id.

I am using this many years now without any problems. Also my collegues and many other folks I know. Thus the question is how your system differs from commonly used systems.

We do not support OpenSSH certificates but ignore such requests. However, the keys from the certificates will be imported correctly. You should use the stable version of GnuPG (2.3.8) and not the LTS version 2.,2.

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.

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

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.

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.

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

$ ping git.gnupg.org
PING git.gnupg.org (217.69.76.56) 56(84) bytes of data.
64 bytes from cvs.gnupg.org (217.69.76.56): icmp_seq=1 ttl=58 time=6.74 ms
64 bytes from cvs.gnupg.org (217.69.76.56): icmp_seq=2 ttl=58 time=6.87 ms

You need to assign a drive letter.

My suggestion is to clearly state that there is a direct Key Signature with an expiration date. Another feature would be to add a separate command to modify Direct Key Signatures. However, the latter has the problem that it help with proliferation of such signatures and other OpenPGP implementation will run into other problems. Thus for the whole ecosystem such an option is might not be a good idea.

Direct key signatures are rarely used. IIRC, we implemented that the same way PGP did it.