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

Sign our own npm package #19170

Closed
HonkingGoose opened this issue Nov 29, 2022 · 13 comments · Fixed by #21608
Closed

Sign our own npm package #19170

HonkingGoose opened this issue Nov 29, 2022 · 13 comments · Fixed by #21608
Assignees
Labels
priority-3-medium Default priority, "should be done" but isn't prioritised ahead of others status:in-progress Someone is working on implementation type:feature Feature (new functionality)

Comments

@HonkingGoose
Copy link
Collaborator

What would you like Renovate to be able to do?

We should look into signing our packages. It's probably a good idea to figure out signing our npm package first to learn how it all works. We can expand signing to our other projects/build artifacts later.

If you have any ideas on how this should be implemented, please tell us here.

GitHub has a blog 1 about using Sigstore on GitHub Actions to sign a build. The key benefit seems to be that with Sigstore you don't have to manage a private key, they call this "keyless signing". It sounds like this all makes signing easier to setup and maintain. 😄

The Sigstore project is now released under General Availability, and GitHub says it's stable to start using now.

I've copy/pasted the most relevant part of the blog below for reference:

Sigstore and GitHub Actions, today

The first thing people do to secure their builds is to sign them, so you can detect if it’s been tampered with between when the build finished and when you’re about to run it. This often requires managing a private key, including generating it correctly, keeping it a secret, and rotating it over time. At best this is a hassle, and at worst it’s a roadblock for folks who don’t have experience in this area. As a result, builds aren’t signed nearly as often as they should be.

When you’re building in a cloud CI/CD provider that supports OIDC tokens, like GitHub Actions, Sigstore can generate a signing certificate for your build without having to maintain a private key. Sigstore calls this keyless signing, and it’s a fantastic example of lowering the barrier to entry so more projects can sign their builds. In fact, this keyless signing is already in use for Kubernetes as well as CPython releases.

To illustrate how to do this, last year we wrote about how to use Sigstore’s cosign to sign container images built in GitHub Actions. While cosign sign assumes your build is a container image, you can also use cosign sign-blob on any type of build output.

These are all things you could already do with Sigstore on GitHub Actions, but general availability is an exciting milestone in terms of maturity: the components have all reached a 1.0+ release, the APIs are stable, and the public servers now have a SLO and a 24/7 on-call rotation. This release is a collaboration across several organizations, and GitHub has directly supported it by contributing to both the development of the Sigstore code as well as the on-call rotation for the servers.

I'll let you maintainers figure out how this all works, and let you set up signing. 😉

Is this a feature you are interested in implementing yourself?

No

Footnotes

  1. https://github.blog/2022-10-25-why-were-excited-about-the-sigstore-general-availability/

@HonkingGoose HonkingGoose added type:feature Feature (new functionality) status:requirements Full requirements are not yet known, so implementation should not be started priority-5-triage labels Nov 29, 2022
@rarkins rarkins added priority-3-medium Default priority, "should be done" but isn't prioritised ahead of others status:ready and removed priority-5-triage status:requirements Full requirements are not yet known, so implementation should not be started labels Nov 29, 2022
@JamieMagee
Copy link
Contributor

There is intent to bring this functionality directly into npm, however it should be possible already using sigstore-js

References:

@HonkingGoose
Copy link
Collaborator Author

Thanks for the links!

Are you sure about using sigstore-js? Here's a quote from their readme:

sigstore-js

⚠️ This project is not ready for general-purpose use! ⚠️

I'll let you decide what to do with this information. 🙂

@JamieMagee
Copy link
Contributor

True, npm package signing is still very early in development. That said, sigstore-js is being added to the npm cli in the provenance branch

@JamieMagee
Copy link
Contributor

I have the solution in a branch, feat/sign-npm. This enables provenance generation by default when running npm publish.

I created an example package with provenance enabled in .npmrc to test the functionality. Unfortunately, I currently get an error when trying to publish the package:

npm ERR! 422 Unprocessable Entity - PUT https://registry.npmjs.org/@jamiemagee%2fprovenance - Publishing with sigstore provenance is not enabled for your account. Contact support if you would like to beta test this feature when it becomes available.

@rarkins
Copy link
Collaborator

rarkins commented Nov 30, 2022

I submitted a request for the publish-bot npm user to be able to sign renovate

@JamieMagee
Copy link
Contributor

@rarkins did you hear back? It looks like GA of the feature is coming soon github/roadmap#657

@rarkins
Copy link
Collaborator

rarkins commented Feb 23, 2023

I don't think I've been notified of anything, can't find any sign of it when I log in either

@JamieMagee
Copy link
Contributor

The feature is now generally available https://github.blog/2023-04-19-introducing-npm-package-provenance/

@HonkingGoose HonkingGoose added status:in-progress Someone is working on implementation and removed status:ready labels Apr 19, 2023
@HonkingGoose
Copy link
Collaborator Author

HonkingGoose commented Apr 19, 2023

Related PR:


@JamieMagee there's a problem with the current setup, the release-npm workflow errors out. Copy/paste of the relevant part of the log output: 1

npm notice === Tarball Details === 
npm notice name:          renovate                                
npm notice version:       35.55.0                                 
npm notice filename:      renovate-35.55.0.tgz                    
npm notice package size:  2.9 MB                                  
npm notice unpacked size: 18.1 MB                                 
npm notice shasum:        73fe5e9564eba81bdcd9cac0e12ea24657bd68db
npm notice integrity:     sha512-jYjDynDfOHE80[...]/UBiS0PW8xing==
npm notice total files:   2968                                    
npm notice 
npm notice Publishing to https://registry.npmjs.org/ with tag latest and default access
npm ERR! code EUSAGE
npm ERR! Automatic provenance generation not supported outside of GitHub Actions

Footnotes

  1. https://github.com/renovatebot/renovate/actions/runs/4747207723/jobs/8431810108#step:9:2996

@JamieMagee
Copy link
Contributor

I was just opening a PR 😓

#21612

@viceice viceice mentioned this issue Apr 20, 2023
6 tasks
@viceice
Copy link
Member

viceice commented Apr 20, 2023

can we close this now?

@HonkingGoose
Copy link
Collaborator Author

This likely fix is now in main

but we don't know if it works. We'll have to wait for a release-worthy commit to land in main, to see if the release-npm step finishes properly.

Then we need to check that we can see the new provenance label on the npm registry for our package. Once all that is done, we can close this issue. 😄

@JamieMagee
Copy link
Contributor

Renovate version 35.55.1 is the first version of Renovate to be signed:

image

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 21, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
priority-3-medium Default priority, "should be done" but isn't prioritised ahead of others status:in-progress Someone is working on implementation type:feature Feature (new functionality)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants