Skip to content

SLSA E2E RFE: The in-toto Policy Framework and Verifier#92

Open
trishankkarthik wants to merge 8 commits intoin-toto:mainfrom
trishankkarthik:trishankatdatadog/slsa-e2e-rfp
Open

SLSA E2E RFE: The in-toto Policy Framework and Verifier#92
trishankkarthik wants to merge 8 commits intoin-toto:mainfrom
trishankkarthik:trishankatdatadog/slsa-e2e-rfp

Conversation

@trishankkarthik
Copy link

@trishankkarthik trishankkarthik commented Sep 23, 2025

As described here.

TODO:

  • Fake Attestations
  • Verify Policy against Attestations
  • Produce Policy VSA
  • Verify Artifact against Policy VSA

@trishankkarthik trishankkarthik marked this pull request as ready for review September 24, 2025 03:44
found = true
}
}
// So basically, we guarantee there is only one subject with the same name and digest.
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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()
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, we should just expose this function somewhere and reuse it.

Copy link
Member

@adityasaky adityasaky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do we need to skip? Not all attestations need to be used against a policy, no?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah you don't want to stick it in the VSA that wraps this policy verification.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we not use IN here and make git+ part of the matched pattern?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can move probes to a separate repo

@@ -0,0 +1,249 @@
# SLSA E2E RFP

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@trishankkarthik trishankkarthik changed the title SLSA E2E RFP SLSA E2E RFE: The in-toto Policy Framework and Verifier Sep 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants