The Case for Farm-to-Table Package Signing
The benefits and limitations of signing an open source package–using a private key to create a unique digital signature–are a surprisingly contentious topic.
One of the maintainers associated with the Python Package Index maintainer has a cogent blog post called “Why Package Signing is not the Holy Grail.” This maintainer criticizes those who view signing packages as some sort of “voodoo” that creates “security.” Another open source software developer documented their frustrating experience discovering “how uninterested developers are in software authentication,” the technical name for signing and verifying packages. The developer even titled this piece “Nobody Cares about Signed Gems,” referring to the name used for Ruby packages.
As part of writing this post, I even did a handful of interviews with open source software developers on the topic of package signing. Here’s a taste of the intensity that at least some developers feel on the topic. I emailed one maintainer, requesting an interview. He declined my interview by writing, “There is nothing to discuss, package signing is needed, and there isn’t one, so [registry X] can be easily f***ed.” Then the email ended.
This acrimony appears to stem from a narrow view of what package signing is, or perhaps, could be. In this view, which might be called plain old package signing, a digital signature is paired to a package and cryptographically links a person (or a private key, technically) to a package. But there’s a broader view possible, one that sees signing as a means of verified attestations about the provenance, build process, and a range of key qualities for an open source package, or what might be called farm-to-table package signing. This broader view, evident in projects like in-toto and sigstore, promises to reduce the hand-wringing associated with the topic and benefit the security of the world’s software supply chain.
Plain Old Package Signing
Package signing has typically referred to an open source maintainer generating a public and private key and then signing a software artifact with the private key, which allows the package user to verify the signature using the associated public key. To proponents of plain old package signing, the benefit then arrives: the signature proves to other parties that the private key holder signed the artifact. To borrow Chainguard CEO Dan Lorenc’s warning: “That’s all it provides though!”
Consequently, skeptics will argue that this link has only modest benefits. As a method for authenticating identity and preventing malicious account takeover (where one party hijacks another account), plain old package signing merely complements a range of other existing techniques such as multi-factor authentication. Some skeptics might also concede that plain old package signing, if paired with a trustworthy registry of package owners, can help ensure package integrity should the entire package registry be compromised. But that’s about it, and the skeptics are right, if package signing is defined as plain old package signing.
Fortunately, there’s a larger vision that is increasingly becoming reality.
Farm-to-Table Package Signing
Farm-to-table package signing implies that plain old package signing ought to be table stakes. The valuable addition of farm-to-table package signing is the use of cryptographically signed claims about the artifact. The in-toto project, which includes an open metadata standard related to software integrity, pioneered this approach. For instance, such a signed claim, which is sometimes called an attestation, could include artifact provenance metadata about the origins of the artifact (e.g. URL to the source code management system and an exact commit) and the build process used. The claim could truly be anything: a comprehensive software bill of materials (SBOM) or vulnerability scan results. Crucially, these attestations can come from parties other than the package maintainer. The organization doing the vulnerability scan, rather than the maintainer, can sign the scan results, boosting the trust a consumer of that artifact can place in that attestation.
This farm-to-table version of package signing–in which attestations about the software artifact’s lifecycle become pervasive–then enables software developers and consumers to make more informed decisions about what to use and operate. For instance, if you or your organization only want to use software artifacts with a comprehensive SBOM that is cryptographically signed, farm-to-table package signing makes this possible.
The Future is Now
To be sure, farm-to-table package signing is not the holy grail. There are many types of software supply chain attacks and no method counters all of them. Most importantly though, unlike the holy grail, farm-to-table package signing has largely arrived. Sigstore, an open source project that provides services for easily signing and verifying software, is making it possible for open source communities and projects to use services that support farm-to-table package signing. In addition, Sigstore improves the trustworthiness of software package signatures by linking signatures to other digital identities, like GitHub accounts, and by providing transparency: a public record of all attestations.
To get involved, consider:
Supporting package signing of the farm-to-table variety in your programming language or open source community. This RubyGems RFC, for example, proposes a new signing mechanism.
Contributing to sigstore at the project’s GitHub, joining the sigstore slack, joining the biweekly community calls, or checking out the project on Twitter.
Thinking of internal use-cases for farm-to-table package signing that could benefit your project or organization. Let us know if we can help here.
Thank you to the open source maintainers and other community members who graciously accepted an interview. Shout out to Jordan Harband especially. You probably depend on one of his 300+ npm packages and, if so, should consider sponsoring his work.
