Unconfigured keyring (default) | Configured keyring | ||||
---|---|---|---|---|---|
R == -1 ("all") | R >= 1 (default) | ||||
F == 0 | F > 0 | S >= R | S < R | ||
U >= 1 | Invalid option error 1 | Success 2 | Fail | Success | Fail |
G >= 1 | Warn | Success 2 | Fail | Success | Fail |
U == 0 and G == 0 | Success | Success 3 | Fail 4 |
- Gives error that the keyring needs to be configured if user wants to use signature verification. I wondered if this should be a warning instead, but made it an error because it seems like this would probably be done by mistake. Signature verification can be toggled off to opt out without ambiguity.
- If I > 0 and S == 0, there were only ignored signatures. I'm considering this a success because no non-ignored signatures could be considered "all". Should this be a warning?
- Sucessful because no signatures could be considered "all".
- Currently a failure because None < R, but should this just be a warning?
- U
- Number of user-provided signatures.
- G
- Number of galaxy-provided signatures.
- R
- Number of required successful signatures.
- S
- Number of signatures that are successful. This does not include signatures which fail but are ignored.
- F
- Number of signatures that fail. This does not include signatures which fail but are ignored.
- I
- Number of signatures that fail but are ignored. This is used to limit the errors a user will see and prevent certain errors from incrementing F.
Update 03-07-2022:
I added support to make signature verification strict (e.g. --required-valid-signature-count +all). The behavior on the left side of the original table (unconfigured keyring which is the default, i.e. keyring is None) is the same, so I didn't put it in this table. I put asterisks next to the things that are a change in behavior.
Assuming the keyring is not None:
R == all | R >= 1 | ||
---|---|---|---|
S == 0 and not strict | Success (F == 0) | U/G == 0 | U/G >= 1 |
Success ** | Fail (S < R) | ||
S == 0 and strict | Fail * | Fail | |
F == 0 | Success | Only S is relevant to R >= 1 | |
F > 0 | Fail | ||
S >= R | Only F is relevant to R == all | Success | |
S < R | Fail |
* Prior to 'strict', this was a verification success. Changed to give 'all' an option to be as strict as R >= 1 and require signature verification occurs.
** Prior to 'strict', this was a verification fail because R < S. Changed to make R >= 1 more lenient, like 'all', if no signatures are found.
This is great- exactly what we need for ensuring that we've got all the cases covered. Thanks for putting it together!
I suspect there are a few problem cases above- a couple that will break things when we someday start configuring a default keyring, and others where security folks will likely be unhappy with it and give us grief once they understand what's happening.
The cases I'm most concerned about future grief on are mostly around the conflation of "unconfigured keyring" and "effectively unconfigured keyring" (ie, one that has no applicable keys, so all signatures are ignored):
My initial thoughts to address all these was to make the
R
config value a composite string rather than just using -1 as a special case- the same thing could probably be accomplished with an explicit "require all content to be signed" switch, but I'll leave that as an exercise for someone else. Maybe make+
the special modifier that turns on the signatures-required behavior as specified in the chart above for configured keyring, and leave the current default as the non-+
version:... or something like that. The concerns that we probably at least need a plan for are:
all
is always stricter than R>=1