Skip to content
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

Unified Source Designation #4

Open
ianlewis opened this issue Jun 2, 2023 · 3 comments
Open

Unified Source Designation #4

ianlewis opened this issue Jun 2, 2023 · 3 comments
Labels
enhancement New feature or request

Comments

@ianlewis
Copy link
Member

ianlewis commented Jun 2, 2023

There is a need for a canonical way for signers to capture the source in the provenance and for verifiers to check. For GHA the source is the repository that triggered the the GHA run, however other dependencies could potentially be pulled and included in resolvedDependencies.

Right now slsa-github-generator includes this information as the first entry in resolvedDependencies by convention and slsa-verifier uses this to verify against the --source-uri provided by users. This is really just a convention and should be included more definitively in the provenance via a field in externalParameters or an annotation on the resolvedDependency entry.

Ideally this solution would be applicable to other builders as well and should not necessarily be decided here. Though the ultimate decision should be reflected in this repo and it's examples.

@joshuagl
Copy link
Member

joshuagl commented Jun 2, 2023

There is a need for a canonical way for signers to capture the source in the provenance and for verifiers to check

This seems incomplete?


Of the three different source types, are the build config info in A not always part of a GHA event? If so, would that make B a subset of A? Put differently, can an event triggering the Action not include the information in A? (Is that why we have a subset of supported event types?)

C appears to describe an entry in resolvedDependencies, are you suggesting we need to model that differently in this buildType?

@MarkLodato
Copy link
Member

There's no way for the the builder to implement C. It cannot know which git repo is the "source" vs any other git repo that is pulled. There's also no technical means for it to detect that at this point.

Right now A and B are the same, due to the restrictions on event types as @joshuagl said.

I don't understand what the request is here.

@ianlewis
Copy link
Member Author

ianlewis commented Jun 2, 2023

This seems incomplete?

Apologies. It was missing a period. As Mark mentioned there is an issue with determining the source repo for the triggering workflow vs. any other pulled or resolved dependency.

I don't understand what the request is here.

I created the issue mostly so we could have the method used to determine the "source" reflected in this repo. I copied and pasted from elsewhere but I'll go ahead and update the description now. Hopefully the new description makes more sense.

I intended this to mostly be a tracking bug to remind me/us to update this repo when we have a better idea how to represent the "source" dependency.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants