Hi, On 01/18/2017 03:51 PM, John Lane wrote:
I think things look ok up to step 9 and point (a) and (b) appear to work as I expect but (c) doesn't. I'd really appreciate some feedback about what is happening in: step 10 (trust level 1 restricted to example.org) step 14 (trust level 2 restricted to example.org) step 16 (trust level 2 restricted to example.es)It would appear that any domain restriction disables trust completely!
I believe there's a bug in the handling of the regular expression associated with a trust signature. I've just submitted a patch to fix it [1]. With that patch applied, I get the expected result for step 10 (Blake's key is fully valid, not the others') and step 14 (Blake's key is fully valid, and so are Chloe's and David's keys).
For step 16, none of the keys are valid, but I think that's the expected behavior: you signed Introducer with a level 2 trust signature restricted to example.es, so the signature of Blake's key (which as an example.org UID) is rightly ignored. Blake's key is thus of unknown validity and his signatures on Chloe's and David's keys are ignored as well.
(Side note: you can use the '%transient-key' directive when batch-generating keys for testing purposes. This instructs GnuPG to use a less secure but faster random number generator, thus speeding up the generation process.)
Damien [1] https://lists.gnupg.org/pipermail/gnupg-devel/2017-January/032472.html
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
