Page MenuHome GnuPG

regexp for trust signature domain restriction does not work if key only has an e-mail address
Closed, ResolvedPublic


Testcase: openPGP public key with no name, only the e-mail address "".
This key is signed by another key (, which is trusted by me as introducer for the domain

Expected: That the key is displayed as valid (certified, marked in green by Kleopatra).

In fact it is marked as invalid/not certified/unknown.

C:\Users\vaughan>gpg --check-trustdb --debug trust
gpg: Optionen werden aus 'C:/ProgramData/GNU/etc/gnupg/gpg.conf' gelesen
gpg: Optionen werden aus '[cmdline]' gelesen
gpg: enabled debug flags: trust
gpg: verwende Vertrauensmodell pgp
gpg: 15 Schlüssel bislang bearbeitet (6 Validity Zähler gelöscht)
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: DBG: trust sig on, sig depth is 1, kr depth is 0
gpg: DBG: replacing trust value 0 with 120 and depth 0 with 1
gpg: Tiefe: 0  gültig:   3  signiert:   3  Vertrauen: 0-, 0q, 0n, 0m, 0f, 3u
gpg: DBG: key EE77B3D57243F72E: update min_ownertrust from 0 to 5
gpg: DBG: key EE77B3D57243F72E: overriding ownertrust 'unbekannt' with 'vollständig'
gpg: DBG: regexp '<[^>]+[@.]demo\.gnupg\.com>$' ('<[^>]+[@.]demo\.gnupg\.com>$') on 'Tina Tester': NO
gpg: DBG: regexp '<[^>]+[@.]demo\.gnupg\.com>$' ('<[^>]+[@.]demo\.gnupg\.com>$') on '': NO
gpg: Tiefe: 1  gültig:   3  signiert:   0  Vertrauen: 2-, 0q, 0n, 0m, 1f, 0u
gpg: nächste "Trust-DB"-Pflichtüberprüfung am 2024-06-21
gpg: secmem usage: 0/32768 bytes in 0 blocks

The regexp only matches <>, not

$ echo |egrep -i '<[^>]+[@.]demo\.gnupg\.com>$'
$ echo '<>' |egrep -i '<[^>]+[@.]demo\.gnupg\.com>$'


VSD 3.1.24

Event Timeline

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.

If you look at C29F8A0C01F35E34D816AA5CE092EB3A5CA10DBA you can see my user IDs that have only an e-mail address are wrapped in angle brackets.

This doesn't solve your problem with the regexp, of course, but it does indicate that it's a bad idea to form user IDs that contain an e-mail address without putting the e-mail address in angle brackets, even though a reasonably concise description of actual, real-world User ID conventions does acknowledge that this is a common pattern.

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.

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.

@werner i'm not sure i understand what "easy to enclose them in angle brackets just for comparison" means.

Currently, with gpg --gen-key in v2.2.40, if the user provides an empty "Real name" and an e-mail address, the emitted User ID is just a raw e-mail address, no angle brackets.

Are you saying that GnuPG will change how such an "e-mail only" User ID will be generated (if the user only provides an e-mail address and no full name), so that it *will* be wrapped in angle brackets?

Or are you saying that when considering whether to rely on a regex-scoped tsig in considering a certification over UID X for the purposes of calculating validity, GnuPG will examine the UTF-8 contents of UID X and potentially prepare an alternate UTF-8 string X' for matching against the tsig's regex?

Or both? or something else?

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.

werner moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Oct 28 2022, 9:48 AM

Fixed for master but not yet tested.

werner changed the task status from Open to Testing.Oct 28 2022, 3:44 PM
werner added a project: backport.
werner moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.
ebo moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Apr 5 2023, 3:13 PM