Add in-toto format with hashes of files as subjects #266
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Note: This is an experiment serialization, one of the 4 in a series of PRs (#264, #265, #266, #267). Before a stable release of the library, we would standardize on an ergonomic format, with as little corner cases / dangerous corners as possible.
This converts model serialization manifests that record every model file hash into an in-toto payload that can then be passed to Sigstore's
sign_intoto
for signing to generate a SigstoreBundle
(if using Sigstore).This time, we record every hash as part of the subject instead of in the payload. We require verifiers to be aware of this and acknowledge that verifiers that only check subject by subject (that is, they check if the hash of a passed in argument is in the list of subjects and don't check if all the hashes are present), can fail to fully detect if the model integrity is compromised by renaming one file in the model, interchanging two file names, or deleting a file. The signing library will have additional checks for this, but verifying the signature with other tools might result in invalid results.
CC @susperius for converting manifest to in-toto. This should cover #111, #224, and #248 (first part of the machinery). CC @laurentsimon and (optionally) @TomHennen to make sure I did not mishandle in-toto.
Note: I still had to pass some payload to the in-toto predicate due to in-toto/attestation#374. Right now, it is a key-val pair that should be ignored, but there is also the possibility of registering only one predicate type for all model signing in-toto formats and then registering a subtype as part of the predicate, that we can control as much as we need.
Note: This is the equivalent of #264, but the individual hashes are now used as subjects. Note the warning about existing tooling that would fail to detect some compromises.
Note: This builds on #265. I decided to split every feature into its own PR to make it easier to review what changes (should be only the last commit) and to be able to merge partial work and continue from there.
Release Note
NONE
Documentation
NONE