src/gpgme.h.in
654	I would not call this "regexp" so that ppl do not start to come up with fancy REs which will end in an OpenPGP incopatibility nightmare. Maybe a neutral name (eg.g something like domain) or at least check that the given RE confirms to a limited format; e.g. by using _gpgme_is_valid_mailboix maybe bey prefixing with "foo@" if there is no "@', like we do it in dirmngr: string = strconcat ("--policy-flags foo@", domain, NULL);

ikloecker added inline comments.May 4 2021, 3:10 PM

src/gpgme.h.in
654	I took the field names from `PKT_signature` (`g10/packet.h`). For now `trust_regexp` is "read-only", i.e. people working directly with the gpgme API can change it all they want. Changing it has no effect (outside of the running process). And, in case of a trust signature, it contains the following value: <[^>]+[@.]example\.org>$ This is clearly a regular expression and not even remotely a valid domain name. Prefixed with `@` it certainly isn't a valid mailbox. But that's okay because it's read-only. Regardless of the above, I'm okay with renaming the field. I suggest `trust_scope` (RFC 4880: "Used in conjunction with trust Signature packets (of level > 0) to limit the scope of trust [...]"). I'll update the patch. The gpgme++/qgpgme API for creating trust signatures will only allow domain names because it uses the edit interactor interface which asks for a domain name.

Renamed trust_regexp to trust_scope.
Use part of _unused for storing trust_depth and trust_value.

Added documentation for the new fields.

This is better name. My point was that if we ever use that to create such a field the developer should not assume that arbitrary REs can be used here. We need to have some practical value here and I would prefer to see only the domain name. However, OpenPGP allows for arbitrary REs and thus we may see them here. This is problematic but we can't do much about it.