NPM Provenance Public Beta | Hacker News Reader

NPM Provenance Public Beta

github.blog

67 pointsjusteleblanc28 comments

FYI there is a push to standardize this stuff under the name of SCITT in IETF [1]. In this case (blog post) this is different as NPM is using in-toto attestation [5] (a description of a thing) and logs it in Google's provided append only log (transparency service). They are trying to make this thing being adopted through a freemium model at the moment.

One issue here is that NIST are trying to push SBOMs [2] but NPM is not providing them as part of the provenance I think.

Another thing is a push to use new types of signature envelopes like DSSE [3] instead of something like COSE [4]

[1] https://datatracker.ietf.org/group/scitt/about/

[2] https://www.nist.gov/itl/executive-order-14028-improving-nat...

[3] https://github.com/secure-systems-lab/dsse

[4] https://www.rfc-editor.org/rfc/rfc8152

[5] https://github.com/in-toto/attestation

SBOM doesn't make sense at this level usually since the things being published lists constraints when installed locally and not locked/pinned versions. Some executables distributed on npm do provide lockfiles but those aren't SBOMs. You cannot really have an SBOM of something with unknown transitive dependencies. There are also disagreements on which SBOM would make sense here as multiple are in play.

> Some executables distributed on npm do provide lockfiles but those aren't SBOMs

Not entirely sure what this sentence means (some executables?), NPM generates lockfiles and, while lockfiles are not SPDX/CycloneDX equivalent, the overlap in intent and content is strong. SBOM makes just as much sense at this level as the existing lockfile generation mechanism.

SCITT is pretty much just a late copy / paste of what sigstore has already done, save swapping out COSE for X509.

SCITT is still nascent. Sigstore is operating and in use by multiple ecosystems. On the principle of "rough consensus and running code", SCITT is not the leader.

> and logs it in Google's provided append only log

This is false. The entire sigstore effort is under the OpenSSF and the production systems are operated by volunteers from multiple companies.

From https://docs.npmjs.com/generating-provenance-statements

    In order to publish a package with provenance, you must build your package with a supported cloud CI/CD provider. Today this includes GitHub Actions, and we are collaborating with additional providers to expand support.

I really hope that's not an empty statement. I enjoy some aspects of Github, but would hate to see it become the only trusted source for an entire language's ecosystem.

npm is GitHub is Microsoft.

If you look at the GitHub announcement in the looking ahead section it says this:

> Working with other cloud CI/CD providers to add support for provenance signing

So hopefully they make good on that point.

https://github.blog/2023-04-19-introducing-npm-package-prove...

> entire language

FYI, sigstore is not js-specific

Shouldn't this be on the npmjs.com blog instead of GitHub? I know that both are owned by Microsoft, but why not use microsoft.com for everything then? Or let things at least appear separated from the outside.

Edit: Oh, realize now that npmjs.com doesn't even have it's own blog/news anymore, it's been absorbed by github.blog already and link on npmjs.com redirects there. Oh well, I'll leave my comment so you all can laugh about how wrong I was.

GitHub owns NPM (And yes Microsoft owns GitHub)

It's incredible how much of the software development space is owned by Microsoft now. I wonder if they will also buy JetBrains in the foreseeable future?

I suspect Microsoft prefers extending the reach of Visual Studio Code over acquiring JetBrains.

I think they'd also prefer to extend the reach of C# over adopting JavaScript. But alas, reality is what reality is.

Well, there is TypeScript so...

If the Bloomberg article[0] about them is to be believed, I don't think they're interested in being acquired

[0]: https://archive.is/WeAEV

better overview on the main release blog: https://github.blog/2023-04-19-introducing-npm-package-prove...

Yes, and second analysis by an independent party: https://socket.dev/blog/npm-provenance

Great work! This provenance check is going to be very valuable for enforcing supply-chain security. We are working on adding support to check for provenance in Packj.

1. https://github.com/ossillate-inc/packj flags risky/malicious NPM/PyPI/Ruby dependencies

All haranguing over details aside, this is great news! I didn't know GitHub/npm was even working on this, and I'm glad to see a reasonable solution to a recognizable problem. Keep it up.

No, thanks. This is a massive platform lock-in.

A more sane way for npm publish would be if the registry would just git checkout your repo during publish and strongly tie the package version to a commit hash.

Thus things without provenance become unusable and Microsoft builds on ownership of npm to exert absolute control over the javascript ecosystem. I reckon I can see how this ends.

Any code licensed under any of the popular OSS licenses are free to be hosted anywhere. If people want to mirror every package on NPM to a new registry, there's nothing Microsoft can do to stop them.

paranoid and false.

The Root CA is generated by the sigstore community (five folks, two from academia). Right now github exchanges an OIDC token for a sigstore root chained cert.

GitLab are currently adding themselves, to have the same capability (several other providers are there as well).

https://github.com/sigstore/fulcio/pull/1097

Yeah, we'll see. You say paranoid, I say extinguish.

Extinguish what exactly? Are people publishing packages to anywhere other than npm, and maybe GitHub? Microsoft already owns both of those, so there is nothing to extinguish.

It's not clear what you're worried about, and I'm skeptical you can articulate it, because it makes no sense.

And I say this as someone who is an extremely paranoid anti-corporate crusader, just like I imagine you are. But in this instance, your worry is misplaced.

My thinking is that the path goes thus:

- build on the record of supply chain compromises in npm to justify a provenance system

- establish yourself as one of the trusted authorities on establishing provenance

- spread fear and doubt about untrusted software

- become the trusted source and supplier of software

- open source becomes synonymous with untrusted software, basically malware

- in microsoft we trust

I think microsoft's land grab over open source software was pretty clearly established when they bought github and the general attitude of "they're nice now, it'll be fine" is going to be judged harshly in the future. Or I'm a paranoid crank with a misplaced mistrust of microsoft, who didn't declare "linux is a cancer" or anything like that.

I understand that line of thinking, but what land are they grabbing? They already possess all of it through npm and GitHub.

Do you think they intend to exclude caches like yarnpkg.com as insecure? I don't see how they would do that, since (1) your cache is a local config variable, not part of package.json, so there's no static analysis that could mark packages downloaded through Yarn as insecure, and (2) all of the key signature metadata is publicly available, so any cache or alternative package manager can implement the same provenance features as npm.

Or are you worried about EEE of the upstream source repositories and CI runners, eg "only packages built through GHA platform can contribute provenance data to npm registry?" I guess I could see that as a more reasonable fear, but as someone else explained to you, it's also unfounded (at least for now - which is maybe your argument), and GitLab is currently working on their own implementation. But even if they tried that, then you could still publish and consume packages from another registry if you wanted to. And I'd like to think that if Microsoft made a hostile move like that, we could count on package managers like yarn to pull provenance data from other sources.

I hate to disappoint you, but it's actually really boring. The people who work on this stuff care about the security of NPM packages. That's the whole story.

Reply on news.ycombinator.com