Signing of distributions

[jasnell]

Ideally, the utility would include the requirement that package manager distributions are signed, with the ability for users to verify the signature on installation.

[arcanis]

That would be neat, especially since each team could bake their public key in Corepack 🤔

However, while we could sign the Yarn 2 releases by writing an header comment containing the signature (because we ship it as a single JavaScript file), it wouldn't be possible for package managers installed from the npm registry tarballs.

The main way I could see it work would be to have some kind of deterministic archive traversal that would compute the signature for all files from the archive minus the signature file, and would compare it to the signature file stored within the archive (that would be added right after packing). However,

• it would require pnpm and npm (optional, since we don't officially expose their entrypoint) to build the relevant infra
• changes in the way the archives are traversed could lead to signature mismatches - I'm worried that would be prone to fail

Apart from that, the only option would be for the npm registry to support detached signatures.

[andersk]

Verifying a SHA-256 hash (#37) would provide much of this benefit without any modifications to the way package managers are distributed.

[aduh95]

AKAICT, none of the package managers that Corepack currently supports sign their releases. If Yarn is the easiest one to sign, could we start with this one? @arcanis do you know if that would be difficult to add a step for that in the Yarn release workflow?

[RichiCoder1]

As it matures, I imagine https://github.com/sigstore/sigstore-js would be a relatively lightweight and excellent way to light up signing of distributions.

[aduh95]

Sigstore seems to be npm package specific, I'm not sure if it would work well for us 🤔

I was thinking on what would be a generic solution, and maybe the following would work: the package manager author would bundle a policy manifest as well as an RSA signature for said manifest file. The upside of that approach is that it would allow the package manager to fine grain the security of their application in a way that's simply not possible currently. wdyt?

[RichiCoder1]

@aduh95 ah! To be clear, that library is calling out and supporting npm packages specifically because it's what the new npm provenance feature is built on.

It will work with any file though, and is currently used for verification in other popular formats like containers and has generic documentation for other formats.

[ljharb]

Note that that provenance feature adds nothing that npm hasn't had for a decade - although using sigstore might make it more agnostic.

[MylesBorins]

Note that that provenance feature adds nothing that npm hasn't had for a decade - although using sigstore might make it more agnostic.

I don't feel this is an accurate representation of what the npm provenance work will provide to publishers.

We are gearing up for a public beta soon and could get folks from the Node.js team into our private beta if you want to try it our in advance. Provenance creates a verifiable link between the repository that created the package and the artifact on the public registry, this is not something that exists today. The npm CLI will be shipping with a command that will be able to be used to verify provenance.

Corepack could potentially bootstrap on this, but it would require either re-implementing verification or building on top of the functionality being built into npm. It would also require that all package managers shipped in corepack publish with provenance, something the npm CLI team, for example, is still working towards being able to accomplish.

[ljharb]

Thanks for clarifying; since the feature didn't go through the full RFC process I'm still not clear on how the link is verifiable while publishing from a machine that's not a blessed CI provider, but I'll certainly pay attention to the feature as it's more widely released to try to learn what I'm missing.