Add APIs for Statement v1 and SLSA Provenance v1 protos #268
Conversation
marcelamelara
force-pushed
the
add-ite6-v1-apis
branch
2 times, most recently
from
8e07a90
to
624e113
Compare
|
I like the ideas here, is the plan to take this all the way through signing the statement using dsse as well? |
@adityasaky Ideally yes. The idea would be to have these sort of generators for each supported predicate type, and switch on the predicate type in a place like runlib before we sign the Statement and generate the DSSE. From the CLI perspective, we may introduce a predicate type flag. Other implementers, like the SLSA provenance generator for GHA might use these APIs directly. What I don't have a solution for yet is how the the predicate contents themselves will be generated/passed into in-toto, especially in the case of informational ITE-9 predicates. |
|
In the interest of keeping PRs small enough and digestible, I'm going to scope this PR at only introducing the new v1 APIs, but not integrating them into the greater |
Signed-off-by: Marcela Melara <[email protected]>
Signed-off-by: Marcela Melara <[email protected]>
Signed-off-by: Marcela Melara <[email protected]>
Signed-off-by: Marcela Melara <[email protected]>
marcelamelara
force-pushed
the
add-ite6-v1-apis
branch
3 times, most recently
from
7a88a51
to
3835580
Compare
Signed-off-by: Marcela Melara <[email protected]>
marcelamelara
force-pushed
the
add-ite6-v1-apis
branch
from
3835580
to
4a2940d
Compare
marcelamelara
changed the title
Signed-off-by: Marcela Melara <[email protected]>
| compliant Statement. If there are any marshalling problems, | ||
| this function returns an error. | ||
| */ | ||
| func PredicatePbToStruct(predicatePb proto.Message) (*structpb.Struct, error) { |
There was a problem hiding this comment.
I wonder if want this to be internal/, I don't think we want to accidentally have people use this. Or it could be a private function in attestation.
There was a problem hiding this comment.
I think I had set it public since it's called from within runlib, but either moving this to internal/ or even as a private function to be called only within GenerateValidStatement() could work. We would have to change the signature of GenerateValidStatement() to take a protobuf message instead of Struct in the latter case, not sure how I feel about that.
|
|
||
| /* | ||
| RDListFromRecord converts a map of artifacts as collected | ||
| by RecordArtifacts() in runlib.go and converts it into a list |
There was a problem hiding this comment.
Can this be expanded with the structure of the map? We may retire RecordArtifacts at some point, it'll be helpful to track this here.
There was a problem hiding this comment.
Just to be 100% sure I've understood what you're asking, you're suggesting we include map[string]map[string][string] in this comment?
Co-authored-by: Aditya Sirish <[email protected]> Signed-off-by: Marcela Melara <[email protected]>
There is for sure some overlap. These can probably be merged fairly easily if I make a few adjustments in my PR. I can remove calling the Attestor and leave that for a future change. Whether it's done in the run function or somewhere else I don't have a strong opinion. However, I do think that the run function is getting a bit bloated and doing too much. Possibly passing it a list of attestors would make the most sense. But, the run function is technically for a Link style metadata... which I view as an attestor. Open to further conversations. In the short term, removing how the Attestor code is called and leaving only the interface and LinkAttestor implementation would at least get it merged. |
|
This has been superseded by in-toto/go-witness#149 . |
This PR adds APIs for generating ITE-6 v1 Statements using the protobuf-based language bindings provided by the in-toto Attestation Framework. This PR also adds protobuf-based APIs that replace the now-deprecated SLSA Provenance v1 structs.
Fixes #260, fixes #265.