-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP feat: Use manifest #112
Conversation
677bae9
to
9291d34
Compare
Signed-off-by: laurentsimon <[email protected]>
Signed-off-by: laurentsimon <[email protected]>
Signed-off-by: laurentsimon <[email protected]>
Signed-off-by: laurentsimon <[email protected]>
bfd0d70
to
70679fa
Compare
Signed-off-by: laurentsimon <[email protected]>
This is now working with sigstore/sigstore-python#962 High-level:
The pre-submit fail because we need to pull the branch from sigstore/sigstore-python#962 |
This is great! Thank you! |
Signed-off-by: laurentsimon <[email protected]>
Signed-off-by: laurentsimon <[email protected]>
files += [f] | ||
stmt = ( | ||
dsse._StatementBuilder() | ||
.subjects( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't the subjects be the files?
My mental model had the statement subjects as the artifacts we want to sign so you get subject[n].name = path
and subject[n].digest = file_hash
. So we would only set the predicate_type
field as sigstore.dev/model-transparency/manifest/v1
and that describes everything we need to know about the subjects. Furthermore, the predicate could then hold metadata like {"hash_algorithm": "abc"}
.
PLMK if there is something I don't get here.
See https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're correct that's how intoto works, but there is some discussion here about whether we want to use intoto or not #111
For this PR, I could not pack files in the subject due to some current limitation on the hash type accepted by sigstore-python library (they only accept known hashes, but we use a parallel hash). And I could not use a non-intoto payload for this PoC, because sigstore-python does not support it yet (WIP).
This is the middle layer of the API design work (sigstore#172). We add a manifest abstract class to represent various manifests (sigstore#111 sigstore#112) and also ways to serialize a model directory into manifests and ways to verify the manifests. For now, this only does what was formerly known as `serialize_v0`. The v1 and the manifest versions will come soon. Note: This has a lot of inspiration from sigstore#112, but makes the API work with all the usecases we need to consider right now. Signed-off-by: Mihai Maruseac <[email protected]>
This is the middle layer of the API design work (sigstore#172). We add a manifest abstract class to represent various manifests (sigstore#111 sigstore#112) and also ways to serialize a model directory into manifests and ways to verify the manifests. For now, this only does what was formerly known as `serialize_v0`. The v1 and the manifest versions will come soon. Note: This has a lot of inspiration from sigstore#112, but makes the API work with all the usecases we need to consider right now. Signed-off-by: Mihai Maruseac <[email protected]>
This is the middle layer of the API design work (sigstore#172). We add a manifest abstract class to represent various manifests (sigstore#111 sigstore#112) and also ways to serialize a model directory into manifests and ways to verify the manifests. For now, this only does what was formerly known as `serialize_v0`. The v1 and the manifest versions will come soon. Note: This has a lot of inspiration from sigstore#112, but makes the API work with all the usecases we need to consider right now. Signed-off-by: Mihai Maruseac <[email protected]>
) * Migrate `serialize_v0` to new API. This is the middle layer of the API design work (#172). We add a manifest abstract class to represent various manifests (#111 #112) and also ways to serialize a model directory into manifests and ways to verify the manifests. For now, this only does what was formerly known as `serialize_v0`. The v1 and the manifest versions will come soon. Note: This has a lot of inspiration from #112, but makes the API work with all the usecases we need to consider right now. Signed-off-by: Mihai Maruseac <[email protected]> * Clarify some comments Signed-off-by: Mihai Maruseac <[email protected]> * Encode name with base64 Signed-off-by: Mihai Maruseac <[email protected]> * Add another test case Signed-off-by: Mihai Maruseac <[email protected]> * Empty commit to retrigger DCO check. See dcoapp/app#211 (comment) Signed-off-by: Mihai Maruseac <[email protected]> --------- Signed-off-by: Mihai Maruseac <[email protected]>
closes #111
blocked on sigstore/sigstore-python#628