-
Notifications
You must be signed in to change notification settings - Fork 49
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
[feature] Re-generate the regression tests for docker-based builder #610
Comments
One thing we discussed here was that in this case
Can do - I suppose this makes sense if it's v1.0 spec to nest inside the inputs rather than directly. I can make a quick turn-around fix for what we decide though. |
We need to decide where we put that data in the provenance for all the builders. Right now it's in the externalParameters in the verify-token code (I think because we copied from the slsa.dev example), but I'm fine having it internalParameters. @ianlewis no objection to this update?
SG. Do you want to also update the verify-token Action as part of the PR? |
Created #611 t update to verifier code. One complication is that depending on the builder (builder vs generator), the Not sure yet what's the best way to do that. |
I'm not sure I totally follow. The distinction between internal and external was "does the user have control over the parameter?". In most cases the user does technically have control over the workflow which is why it's in external parameters. At least that's how I understood it.
I suppose I see the docker image itself as analogous to the "run scripts" for the Node.js builder. Yes, these can and probably should be agnostic to the actual workflow that runs them, but the boundary that matters from SLSA's perspective is still the reusable workflow boundary. |
I am not sure why we need to nest the parameters under an Regarding |
the The other In this case is the resolution to revert slsa-framework/slsa-github-generator#2165 and add |
This is what I'm referring to https://slsa.dev/provenance/v1#buildType
This means that the I'm not arguing one way or another! It's just confusing to me. |
I think so. I think it is used to avoid collision with buildType-defined custom fields. It's simpler to keep the same format across GH builders, this way the slsa-verifier has a unique function to retrieve the inputs |
Hmmm this might help with my confusion above.
The resolution could be:
Let's discuss what to do about |
I agree that given this maybe not feasible to reuse the full buildType for other build systems. Is there some subset that could be the same though? IIUC, parameters could have any kind of structure it wants (though there is some leaning towards a more flat structure) so part of it could be a fully reusable bit. Would that achieve any of your goals? |
SG. I think you can drop it so long as you record the |
- Included typescript-eslint - This is based on https://github.com/actions/typescript-action - Fixes slsa-framework#610 Signed-off-by: naveensrinivasan <172697+naveensrinivasan@users.noreply.github.com> Co-authored-by: Ian Lewis <ianlewis@google.com>
The attestation currently does not follow the v1.0 specs:
It should instead nest the inputs into an
inputs
field:I would also be useful to add workflow:
to help during troubleshooting or incidence response.
Should be fixed in the generator before GA
/cc @asraa @rbehjati
The text was updated successfully, but these errors were encountered: