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

feat: support npm cli provenance v1 attestations #776

Merged
merged 26 commits into from
Jul 30, 2024

Conversation

ramonpetgrave64
Copy link
Contributor

@ramonpetgrave64 ramonpetgrave64 commented Jun 4, 2024

Fixes #614, #450, #449, #515

Adds support for NPM CLIs build provenances, generated when running npm publish --provenance --access public from a GitHub Actions workflow.

Testing

  • added unit tests for some new helper functions
  • added regression test cases

Future work

Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
@ramonpetgrave64
Copy link
Contributor Author

My implementation turns out to be very similar to another earlier draft in #706

@ramonpetgrave64 ramonpetgrave64 marked this pull request as ready for review June 4, 2024 17:01
@ramonpetgrave64
Copy link
Contributor Author

Copy link

@loosebazooka loosebazooka 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 looks good. It'd be nice to see an actual npm provenance included in here for documentation (instead of having to go parse the dsse envelope)

verifiers/internal/gha/provenance_forgeable.go Outdated Show resolved Hide resolved
verifiers/internal/gha/slsaprovenance/v1.0/base.go Outdated Show resolved Hide resolved
verifiers/internal/gha/slsaprovenance/v1.0/base.go Outdated Show resolved Hide resolved
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
@ramonpetgrave64
Copy link
Contributor Author

@slugclub

Copy link

@slugclub slugclub left a comment

Choose a reason for hiding this comment

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

Thanks so much for looking at this, v1 support will be great!

verifiers/internal/gha/npm.go Outdated Show resolved Hide resolved
@@ -9,13 +9,21 @@ import (
"github.com/slsa-framework/slsa-verifier/v2/verifiers/internal/gha/slsaprovenance/common"
"github.com/slsa-framework/slsa-verifier/v2/verifiers/internal/gha/slsaprovenance/iface"
slsav02 "github.com/slsa-framework/slsa-verifier/v2/verifiers/internal/gha/slsaprovenance/v0.2"
slsav1 "github.com/slsa-framework/slsa-verifier/v2/verifiers/internal/gha/slsaprovenance/v1.0"
)

func verifyProvenanceMatchesCertificate(prov iface.Provenance, workflow *WorkflowIdentity) error {

Choose a reason for hiding this comment

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

This isn't new with this change, but it seems this function assumes that the provenance is going to be generated by GitHub but its possible that it comes from elsewhere (e.g. GitLab https://registry.npmjs.org/-/npm/v1/attestations/@ps-testing%2fgitlab-npm-provenance@1.0.19). Is my interpretation correct? Are there any plans to support verifying provenance that doesn't come from GitHub?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

As they're still on provenance v0.2, I think I agree with laurent that we should wait until they start generating slsa v1 provenance

Copy link

@slugclub slugclub Jun 26, 2024

Choose a reason for hiding this comment

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

OK that makes sense. My only other concern would be making sure the errors the library returns if you try to verify an unsupported type of provenance (e.g. gitlab v0.2) are clear. This switch statement defaults to calling verifySystemParameters for any type that isn't slsav1.NpmCLIGithubActionsProvenance (with verifySystemParameters assuming its a GitHub attestation). Another way to do it would be to check for all expected types and then default to returning some "unsupported type" error, to make it clear to external clients what's going on. But maybe this is handled elsewhere in the code before it gets to this function?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, earlier in the code, the codepath is routed based on BuilderID,

  • for _, v := range register.SLSAVerifiers {
    if v.IsAuthoritativeFor(name) {
    return v, nil
    }
    }
    // No builder found.
    return nil, fmt.Errorf("%w: %s", serrors.ErrorVerifierNotSupported, *builderOpts.ExpectedID)
  • func (v *GHAVerifier) IsAuthoritativeFor(builderID string) bool {
    // This verifier only supports builders defined on GitHub.
    return strings.HasPrefix(builderID, httpsGithubCom)
    }

and will error for unsupported builders, like those from GitLab.

Copy link

@slugclub slugclub Jun 28, 2024

Choose a reason for hiding this comment

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

OK that's great, thanks

Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
@ramonpetgrave64
Copy link
Contributor Author

I think this looks good. It'd be nice to see an actual npm provenance included in here for documentation (instead of having to go parse the dsse envelope)

I added some docs in a new commit

@ramonpetgrave64
Copy link
Contributor Author

@laurentsimon @ianlewis

@ramonpetgrave64 ramonpetgrave64 requested a review from ianlewis June 26, 2024 15:11
@@ -9,13 +9,21 @@ import (
"github.com/slsa-framework/slsa-verifier/v2/verifiers/internal/gha/slsaprovenance/common"
"github.com/slsa-framework/slsa-verifier/v2/verifiers/internal/gha/slsaprovenance/iface"
slsav02 "github.com/slsa-framework/slsa-verifier/v2/verifiers/internal/gha/slsaprovenance/v0.2"
slsav1 "github.com/slsa-framework/slsa-verifier/v2/verifiers/internal/gha/slsaprovenance/v1.0"
)

func verifyProvenanceMatchesCertificate(prov iface.Provenance, workflow *WorkflowIdentity) error {
Copy link

@slugclub slugclub Jun 26, 2024

Choose a reason for hiding this comment

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

OK that makes sense. My only other concern would be making sure the errors the library returns if you try to verify an unsupported type of provenance (e.g. gitlab v0.2) are clear. This switch statement defaults to calling verifySystemParameters for any type that isn't slsav1.NpmCLIGithubActionsProvenance (with verifySystemParameters assuming its a GitHub attestation). Another way to do it would be to check for all expected types and then default to returning some "unsupported type" error, to make it clear to external clients what's going on. But maybe this is handled elsewhere in the code before it gets to this function?

README.md Outdated Show resolved Hide resolved
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
haydentherapper
haydentherapper previously approved these changes Jul 1, 2024
@ramonpetgrave64 ramonpetgrave64 enabled auto-merge (squash) July 23, 2024 19:13
@ramonpetgrave64 ramonpetgrave64 requested a review from a team as a code owner July 25, 2024 19:41
@ramonpetgrave64
Copy link
Contributor Author

@haydentherapper

@ramonpetgrave64 ramonpetgrave64 merged commit 7f3db92 into slsa-framework:main Jul 30, 2024
15 checks passed
@ramonpetgrave64 ramonpetgrave64 deleted the npm-slsa-1.0 branch July 30, 2024 19:46
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.

Support verification for npm SLSA v1.0
4 participants