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.
@nitzmahone I'm still digesting your reply, but my chart is ambiguous about what a "configured" keyring is. By "configured", I mean the ansible-galaxy caller provides a non-null value to
--keyring
(or the global config). There is no keyring inspection and setting the keyring is just how to opt-into signature verification (rather than the original plan of only having a way to opt-out and having the keyring set to a sensible default). Regardless of whether or not the keyring or its directory exist or if it contains any keys, we just pass it along to gpg.If the keyring isn't functional, gpg seems to have sensible errors. For example, if a keyring is provided and the keyring directory does not exist it will cause the gpg error codes ERROR, FAILURE, and UNEXPECTED, so it always fail signature verification (because no signatures will be successful and R == 1 by default). If they also set the required number of signatures to -1/all, then they will also have to ignore all three of those GPG errors to 'pass' signature verification.
This is really counter intuitive to me. The behavior in devel is like "all" (albeit with no option to ignore errors yet) - use all signatures we find, but don't expect them. If this changes to be more strict than R >= 1, there will be no way to reproduce that behavior - the user will need to find out if there are supposed to be signatures beforehand on the Galaxy server and install that collection separately with signature verification turned off if there aren't any.
I really like your idea to solve the "all content must be signed, and all non-ignored signatures must validate" with a modifier. I'll work on that.