Support for multi-subject attestations using different hash algorithms #361
Conversation
|
Currently, this PR is a draft containing only a multi-digest hashing tool. |
Signed-off-by: Cody Soyland <[email protected]>
…sfy subject discovery in multi-subject attestations Signed-off-by: Cody Soyland <[email protected]>
codysoyland
force-pushed
the
multi-subject-digest
branch
from
f148b5d to
afa1b7b
Compare
Signed-off-by: Cody Soyland <[email protected]>
Signed-off-by: Cody Soyland <[email protected]>
Signed-off-by: Cody Soyland <[email protected]>
| // go through the statement and make a simple data structure to hold the | ||
| // list of hash funcs for each subject (subjectHashFuncs) | ||
| for i, subject := range statement.Subject { | ||
| for alg := range subject.Digest { |
There was a problem hiding this comment.
Should we err out if digest is empty? This is the current behavior.
There was a problem hiding this comment.
Interpreting the spec to say the subject is invalid if the digest is the empty string seems pretty defensible to me / 👍 to erroring out on empty digests?
There was a problem hiding this comment.
I'm a little iffy on this, because verification may still pass if there exists a subject with the given digest, even if a subject exists that does not contain a digest. I'm not sure it's the responsibility of the verifier to make sure every subject contains a digest.
| return nil, errors.New("no subjects found in statement") | ||
| } | ||
|
|
||
| supportedHashFuncs := []crypto.Hash{crypto.SHA512, crypto.SHA384, crypto.SHA256} |
There was a problem hiding this comment.
Can this be a constant?
There was a problem hiding this comment.
Slices are mutable and therefore cannot be declared as constants.
There was a problem hiding this comment.
| supportedHashFuncs := []crypto.Hash{crypto.SHA512, crypto.SHA384, crypto.SHA256} | |
| supportedHashFuncs := map[crypto.Hash]struct{}{ | |
| crypto.SHA512: {}, | |
| crypto.SHA384: {}, | |
| crypto.SHA256: {}, | |
| } |
And of course for the other slices too.
this way we can just use _, found := supportedHashFunc[someHashFunc] and remove some custom code that manages all the checking. WDYT?
There was a problem hiding this comment.
I was just looking and can't really find what custom code we could remove if we use a map here. I'm using the generic slices.Contains in a few places so I think that's equivalent to your suggestion?
|
|
||
| // Look for artifact digest in statement | ||
| for _, subject := range statement.Subject { | ||
| for alg, digest := range subject.Digest { | ||
| hexdigest, err := hex.DecodeString(digest) | ||
| for alg, hexdigest := range subject.Digest { |
There was a problem hiding this comment.
Another idea for an optimization is to create the mapping between subject and the algorithms and expected digests in one pass. With this proposed solution, we make two passes, one to build the digest algorithms and one to verify the digests, which would be a performance regression from the previous solution.
There was a problem hiding this comment.
Given that would require shifting a lot of logic into the already tested getHashFunctions (if I understand correctly), I'm not too concerned about the performance penalty of iterating through the digests here again. I do think it's worth revisiting when/if we implement #363.
Co-authored-by: Hayden B <[email protected]> Signed-off-by: Cody Soyland <[email protected]>
Signed-off-by: Cody Soyland <[email protected]>
Signed-off-by: Cody Soyland <[email protected]>
Summary
Support for attestations with multiple subjects using different hash algorithms.
#360
Release Note
Documentation