added ite6 processor with unit tests

[pxp928]

Signed-off-by: pxp928 parth.psu@gmail.com

Added ITE6 processor that will run and determine if the predicate type is SLSA and unpack the predicate. This will need to be replaced with runtime checks of the predicate such that we dont have to keep updating GAUC as new predicate becomes available.

Fixes: #36

[lumjjb]

hmm, i think this is a point of discussion, is DocumentSLSA the entire intoto JSON or the contents of the predicate? This does make sense, but also SLSA provenance definition is based on the entire document as well (https://slsa.dev/provenance/v0.2).

[pxp928]

Right. Should it be the whole provenance or just the predicate was the question.

[mlieberman85]

I have some thoughts around this. Hard to type out. In the graph it might make sense because we establish the relationship through edges anyway.

[mlieberman85]

Also FWIW, folks have recognized that the SLSA stuff is a bit backwards. We should be separating provenance from the in-toto wrapper, otherwise we end up with situations where we make it difficult to have composite types.

[lumjjb]

i think the tricky part here though is that some of the information is missing as as a standalone predicate payload - i.e. the subject will not be available. Which makes me want to tend towards having SLSA be the entire ITE6, for ease of implementation initially.

[pxp928]

Isn't that why the doc tree was created. This would be similar to the DSSE processor where we just store the payload. Losing the signature information.

[lumjjb]

I think the main motivation was more for trust validation to simplify the processor.

This makes the ingestor less modular since a SLSA document ingestor now needs to somehow feed information from the parent node - which may or may not exist. Then some kind of map would need to be passed down but figuring out if a field was from the parent or previous ancestors would need to be considered as well.

I guess the question would be if a document (minus trust validation) should be self contained. Like SBOMs describe the subject within itself through an identifier. Slsa should also duplicate that information within its predicate payload?

[lumjjb]

I think the main motivation was more for trust validation to simplify the processor. This makes the ingestor less modular since a SLSA document ingestor now needs to somehow feed information from the parent node - which may or may not exist. Then some kind of map would need to be passed down but figuring out if a field was from the parent or previous ancestors would need to be considered as well. I guess the question would be if a document (minus trust validation) should be self contained. Like SBOMs describe the subject within itself through an identifier. Slsa should also duplicate that information within its predicate payload?

…

On Sat, Aug 27, 2022, 7:48 AM Parth Patel ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In pkg/handler/processor/ite6/ite6.go <#39 (comment)>: > + } + + statement, err := parseStatement(i.Blob) + if err != nil { + return nil, err + } + var doc *processor.Document + predicatePayload, err := getPredicate(statement) + if err != nil { + return nil, err + } + switch pt := statement.PredicateType; pt { + case string(slsaPredicateType): + doc = &processor.Document{ + Blob: predicatePayload, + Type: processor.DocumentSLSA, Isn't that why the doc tree was created. This would be similar to the DSSE processor where we just store the payload. Losing the signature information. — Reply to this email directly, view it on GitHub <#39 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXLDBWXG7HF6EC7W2AMFQTV3H6APANCNFSM57WWDLQQ> . You are receiving this because you commented.Message ID: ***@***.***>

[mlieberman85]

Yeah. Might be worthwhile to get @SantiagoTorres thoughts on it?

When unpacking documents we're always going to lose something.

1. Unpack envelope -> lose signature info
2. Unpack ite6 -> lose subject

There are a few different approaches here though.

1. Don't unpack, just transform the original doc directly
2. Unpack but encode it into the DocTree somehow?
3. Some hybrid of above?

I think I still prefer 2, because of the proposed changes to sigstore with bundles that would allow multiple things.

[lumjjb]

Documenting what was discussed during our conversation:

We agreed that in the long term, the ingestor would need to have a way to communicate information up/down the tree in order to make edges and annotations between the elements of each node in the document tree.

However, in the meantime, it would be simpler to assume that the information is all encapsulated within the same document. Thus, for now, we will have

• DocumentITE6SLSA
• DocumentITE6Unknown

and ingestor plugins for each that will be handled independently.

[pxp928]

Updated based on the conversation. #53 to update for the future implementation.

[lumjjb]

I think this just returns nil, nil

[lumjjb]

unpack of len 0 output means that it is a leaf node. The guesser would be able to determine if its SLSA or ITE6 so this should not be the case where a processor needs to relabel a document.

[pxp928]

The guesser would be able to determine if its SLSA or ITE6 so this should not be the case where a processor needs to relabel a document.

In that case is the ITE6 Processor needed at all? Seems like its not doing anything that the guesser isnt already doing.

[lumjjb]

lgtm