This adds support for trust signatures to the key list result. This is needed for T5245: Kleopatra: Add support for trust signatures / trusted introducer resp. its subtask T5419: gpgme: Add support for trust signatures to key list result.
- Maniphest Tasks
- T5419: gpgme: Add support for trust signatures to key list result
- rKLEOPATRA5e9d402be380: Yet another place with deprecated API
Run ./run-keylist --sigs and check the printed values for trust depth, trust value, trust regexp.
Unit Tests Skipped
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);
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:
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.
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.