feat: support npm cli provenance v1 attestations

[ramonpetgrave64]

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

• [feature][npm] Verify consistency between cert and provenance #493, so we can do --print-provenance
  • implemented in feat: VerifyNpmPackage API with supplied tuf client #768 (comment)

[ramonpetgrave64]

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

[ramonpetgrave64]

@laurentsimon @ianlewis @haydentherapper

[loosebazooka]

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)

[ramonpetgrave64]

@slugclub

[slugclub]

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

[slugclub]

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%[email protected]). Is my interpretation correct? Are there any plans to support verifying provenance that doesn't come from GitHub?

[ramonpetgrave64]

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

• Support for GitLab provenance #593 (comment)

[slugclub]

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?

[ramonpetgrave64]

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

• slsa-verifier/verifiers/verifier.go

  Lines 26 to 32 in 96619e4

  	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)

• slsa-verifier/verifiers/internal/gha/verifier.go

  Lines 42 to 45 in 96619e4

  	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.

• https://github.com/npm/cli/blob/22731831e22011e32fa0ca12178e242c2ee2b33d/workspaces/libnpmpublish/lib/provenance.js#L74C31-L74C45

[slugclub]

OK that's great, thanks

[ramonpetgrave64]

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]

@laurentsimon @ianlewis

[slugclub]

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?

[ramonpetgrave64]

@haydentherapper