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 Sigstore Bundle (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 https://github.com/in-toto/attestation/issues/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.
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_intotofor 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 https://github.com/in-toto/attestation/issues/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