SLSA E2E RFE: The in-toto Policy Framework and Verifier#92
SLSA E2E RFE: The in-toto Policy Framework and Verifier#92trishankkarthik wants to merge 8 commits intoin-toto:mainfrom
Conversation
| found = true | ||
| } | ||
| } | ||
| // So basically, we guarantee there is only one subject with the same name and digest. |
There was a problem hiding this comment.
Well, not one subject, but that all subjects with the same name have the same digest, and those with same digest have the same name.
| } | ||
| defer artifactFile.Close() | ||
|
|
||
| hasher := sha512.New() |
There was a problem hiding this comment.
Actually, we should just expose this function somewhere and reuse it.
adityasaky
left a comment
There was a problem hiding this comment.
I think this is looking like a solid submission to the RFP!
| attestations := map[string]*dsse.Envelope{} | ||
| for _, attestationDirEntry := range attestationsDirEntries { | ||
| filename := attestationDirEntry.Name() | ||
| // FIXME: Terrible hack to skip the policy VSA, but whatever, it works for now. |
There was a problem hiding this comment.
why do we need to skip? Not all attestations need to be used against a policy, no?
There was a problem hiding this comment.
ah you don't want to stick it in the VSA that wraps this policy verification.
There was a problem hiding this comment.
Do we need both of these:
a) code to mock generate attestations
b) the attestations themselves
If we have a, we don't need to worry about skipping a checked in policy verification VSA. If we have b, this PR gets substantially more straightforward.
There was a problem hiding this comment.
Yeah, it's a tradeoff as you observed. I think we need (a) because it's useful for people to be able to play with different attestations and policies at the same time, but it may not belong in this repo let alone this PR. We could just check in (b), but I think it's less desirable because they seem more magical (no idea how to generate new or even just modified attestations).
| if rule[prefix] != "" { | ||
| rule[prefix] = path.Clean(rule[prefix]) | ||
| if !strings.HasSuffix(rule[prefix], "/") { | ||
| // FIXME: What is the logic for tampering with user-given prefixes? |
There was a problem hiding this comment.
IN was originally intended for sub directory matching. If a user doesn't provide a trailing slash and we don't add one, then IN foo will match foo/bar.txt and football.txt.
| - "937101f8dcc7be06fd1f8c35dbbe9855d784c690e9598a5f11c9b70a0bf46f1f" | ||
| - name: "build" | ||
| expectedMaterials: | ||
| - "MATCH https://github.com/{github_repository}/* IN git+ WITH PRODUCTS FROM source" |
There was a problem hiding this comment.
Can we not use IN here and make git+ part of the matched pattern?
There was a problem hiding this comment.
We can't say MATCH git+https://github.com/{github_repository}/* WITH PRODUCTS FROM source, can we? That wouldn't work IIUC because the products in source are just https://github.com/{github_repository}/.
| @@ -0,0 +1,105 @@ | |||
| // Package probes implements ways to sign and store attestations. | |||
There was a problem hiding this comment.
Copied from elsewhere:
Do we need both of these:
a) code to mock generate attestations
b) the attestations themselves
If we have a, we don't need to worry about skipping a checked in policy verification VSA. If we have b, this PR gets substantially more straightforward.
There was a problem hiding this comment.
I can move probes to a separate repo
| @@ -0,0 +1,249 @@ | |||
| # SLSA E2E RFP | |||
|
|
|||
There was a problem hiding this comment.
Would be good to add some text about what the demo shows e2e? i.e.,
We have some attestations, here's what the supply chain looks like, here's what the policy verified, etc.
There was a problem hiding this comment.
Yeah, Snahil and I were discussing this today, and we think it's best to keep the writeup in a separate Gdoc for now for easier commenting.
As described here.
TODO: