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

refactor: generalize provenance out of predicate type info #463

Merged
merged 5 commits into from
Feb 3, 2023

Conversation

asraa
Copy link
Contributor

@asraa asraa commented Feb 3, 2023

Signed-off-by: Asra Ali asraa@google.com

This generalized the provenance we verify in GHA to work against a generic Provenance interface, which may be provenance v0.2 or soon, v1.0

We can eventually move this package into the common code, when GCB also makes a migration.

Signed-off-by: Asra Ali <asraa@google.com>
Signed-off-by: Asra Ali <asraa@google.com>
Signed-off-by: Asra Ali <asraa@google.com>
Signed-off-by: Asra Ali <asraa@google.com>
verifiers/internal/gha/slsaprovenance/v0.2/provenance.go Outdated Show resolved Hide resolved

// GetStringFromEnvironment retrieves a string parameter from the environment
// attested to in the provenance.
GetStringFromEnvironment(name string) (string, error)
Copy link
Contributor

@laurentsimon laurentsimon Feb 3, 2023

Choose a reason for hiding this comment

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

do you want to go further and have the high-level functions Branch(), Tag()?
This would work also for v1.0, but would look inside systemParameters... Can iterate later if it's too early to optimize now :-) Or maybe it's a bad idea. Just suggesting

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, I was a little bit unsure. On one hand it makes it very clear what info we require from the provenance. On the other hand I wasn't too sure to optimize away all of this too early.

I will follow-up w/ an issue and mark as fixed when I add the v1.0 impl

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

SG!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

FWIW i'm leaning towards exposing the high-level functions. Addressing in my next follow-up!
Thanks!

Copy link
Contributor

Choose a reason for hiding this comment

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

sure, no urgency on this

@@ -564,7 +574,7 @@ func Test_VerifyWorkflowInputs(t *testing.T) {
"some_bool": "true",
"some_integer": "123",
},
expected: serrors.ErrorInvalidDssePayload,
expected: serrors.ErrorMismatchWorkflowInputs,
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Reviewers: I had to update this testcase and the error it generated because it was actually a weirdly formed DSSE envelope input (doubly encoded), and my code made it fail when it was detecting predicateType. Meanwhile, the error had to change from InvalidDssePayload to the actual error check, which is mismatch workflow inputs.

Signed-off-by: Asra Ali <asraa@google.com>
@asraa asraa enabled auto-merge (squash) February 3, 2023 23:24
@asraa asraa merged commit fec5b6a into slsa-framework:main Feb 3, 2023
ramonpetgrave64 pushed a commit to ramonpetgrave64/slsa-verifier that referenced this pull request Apr 18, 2024
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.

2 participants