The Sigstore project is sponsored by companies including Google, Red Hat and VMmware, and overseen by the Linux Foundation. It was launched in March 2021, with the Google security team saying that “installing most open source software today is equivalent to picking up a random thumb-drive off the sidewalk and plugging it into your machine.”
Sigstore is not just another code signing tool. Its normal approach is to remove the need for managing signing keys by issuing short term keys based on OpenID Connect (OIDC) identities, while also recording the actions in an immutable ledger called rekor. Sigstore has its own certificate authority called Fulcio.
The GitHub RFC explains that Fulcio forms an “independent party to validate claims of the OIDC identity token which contains references back to the repo, workflow run and git SHA” – the SHA being a hash that verifies what source code was used for the build. In turn, Rekor “verifies that the signing happened during the time the certificate was valid.”
Sigstore signing has also been proposed for other package registries including RubyGems (for Ruby) and PyPI (for Python).
There are a few drawbacks to the proposal. One is that Sigstore is not done yet, describing itself as experimental. “These warnings are in place because the infrastructure is currently operated on a best-effort basis, and we’ve been learning how to run the system under load as we go,” said Dan Lorenc, Sigstore co-founder. The RFC states that “we remain open to an alternative solution if Sigstore is not able to meet npm’s requirements for uptime and support.”
There are also concerns, referenced in the RFC itself, about what is called “vendorization”, meaning reliance on third parties such as GitHub, Google or Microsoft, and loss of privacy as Sigstore certificates include email addresses by default. The Sigstore proposal will only work for public npm packages with public source repositories and commercial, hosted CI/CD providers. A developer building a package on their own machine, or with a self-hosted CI/CD system, will not be able to participate.
The risk of lock-in seems real even if unintended. “Only GitHub Actions is fully supported in Fulcio today,” says the RFC, though adding “we’d like to see support added for any public CI/CD service” that can meet the requirements, including Circle CI, GitLab, and Google Cloud Build.
“If this means that GitHub Actions are the only way to publish verified packages, I’m a hard and vocal -1 on this until that’s not the case,” responded Twilio developer advocate Tierney Cyren.
The RFC has already provoked considerable discussion with comments ranging from warm welcome to concern that this is a burden and not a benefit to package maintainers. “Are there any more maintainer-focused goals?” added Cyren. “Right now, I see very little incentive for maintainers to be excited for this outside of ones like me who work at companies and get paid to do this kind of maintenance.”