[question] Feedback on Node.js builder

[ianlewis]

Hi! We noticed you were using the SLSA Node.js builder. Really great job using it, you seem to have understood it well! 👍

We were wondering how it was going and if there was any feedback you could provide so we could address it during the beta.

I noticed from your publish.yml that you were using yarn or lerna. I was wondering if anything was blocking you from using the publish action described in the Node.js builder's getting started docs? I'm curious about the choice of using lerna and if we couldn't support it better.

[tirumerla]

Hello @ianlewis , thanks for reaching out and thank you for contributing & maintaining such an awesome framework/tool for us to achieve security best practices.

we started using recently and it's been going great for us. I recently added slsa to on our private repo as well.

Couple of things i observed

• In the latest version 1.7.0 looks like PR webhook has been removed started seeing failures - https://github.com/OpenZeppelin/defender-client/actions/runs/5262925695/jobs/9512590936

• We also see by default provenance checks for github.ref, would be great to allow to trigger on arbitrary inputs ( not a big deal but would be useful if we want to reuse a specific workflow which has provenance now it would always gets github.ref from called workflow rather than specific inputs ( different tag/branch etc.. ) that we want to pass to the next workflow.

• Addition of sbom-action directly within the builder/during release could be a good addition, to automatically generate sbom instead of us creating a separate action to generate and attach to the release.

I noticed from your publish.yml that you were using yarn or lerna. I was wondering if anything was blocking you from using the publish action described in the Node.js builder's getting started docs? I'm curious about the choice of using lerna and if we couldn't support it better.

Thanks. We initially used lerna to automate the whole build, release process by automatic tags in git. In recent days we are managing git flow outside of lerna we are looking at using your publish action we should be soon transitioning to it.... ( just thinking about flexibility of publishing RC releases on demand & publishing "stable" releases automatically everytime there is a non-rc tag.

[ianlewis]

Hello @ianlewis , thanks for reaching out and thank you for contributing & maintaining such an awesome framework/tool for us to achieve security best practices.

Thanks! and thank you for trying it out!

• In the latest version 1.7.0 looks like PR webhook has been removed started seeing failures - https://github.com/OpenZeppelin/defender-client/actions/runs/5262925695/jobs/9512590936

Ah yes. pull_request events are hard for us to support since you cannot create OCID tokens (id-token: write permissions) on pull requests since they can be created by anyone. See: slsa-framework/slsa-github-generator#358 and slsa-framework/slsa-github-generator#131

We're looking at ways to support it properly. In your use case you're just building to verify the project actually builds before merging the PR?

• We also see by default provenance checks for github.ref, would be great to allow to trigger on arbitrary inputs ( not a big deal but would be useful if we want to reuse a specific workflow which has provenance now it would always gets github.ref from called workflow rather than specific inputs ( different tag/branch etc.. ) that we want to pass to the next workflow.

We have been looking to allow users to pass a different sha. We do have to be careful because we want to make sure the build information included in provenance is accurate and cannot be forged somehow.

• Addition of sbom-action directly within the builder/during release could be a good addition, to automatically generate sbom instead of us creating a separate action to generate and attach to the release.

Cool. We do have an issue for this: slsa-framework/slsa-github-generator#1982
Please comment there with more info on your use case.

Thanks. We initially used lerna to automate the whole build, release process by automatic tags in git. In recent days we are managing git flow outside of lerna we are looking at using your publish action we should be soon transitioning to it.... ( just thinking about flexibility of publishing RC releases on demand & publishing "stable" releases automatically everytime there is a non-rc tag.

Awesome! lerna should be able to support uploading the provenance so you could still do it yourself. You'll need to set the download the attestation using secure-attestations-download (as you have been doing in publish.yml) and set the file path to the provenanceFile npm config parameter. I think you're doing something similar with the provenance config parameter here however this will have lerna/npmlibpublish generate its own provenance rather than using the provenance generated by the Node.js builder workflow.

I hope to write some docs for lerna specifically soon so it should be easier for folks who use it.

[tirumerla]

Thank you for taking time to respond.

In your use case you're just building to verify the project actually builds before merging the PR?

Yep that is correct.

We have been looking to allow users to pass a different sha. We do have to be careful because we want to make sure the build information included in provenance is accurate and cannot be forged somehow.

💯 agree. I did realize that was the basis of the design on why only github.ref is supported.

however this will have lerna/npmlibpublish generate its own provenance rather than using the provenance generated by the Node.js builder workflow.

That is true, we are hoping once we transition to slsa publish action we should be able to leverage provenance flags directly during publish.

[ianlewis]

We have been looking to allow users to pass a different sha. We do have to be careful because we want to make sure the build information included in provenance is accurate and cannot be forged somehow.

💯 agree. I did realize that was the basis of the design on why only github.ref is supported.

That isn't to say we can't do it. It just means it requires a bit more thought on our part to make sure. It's a good suggestion so we'll definitely look into it.