Here's the thing about me. I'm an overbearing asshole. As such, I don't really like npm. No good reason to speak of. I've dabble with yarn and pnpm, and internal npm registries, and lockfiles and sha hashes and IPFS and all that.
I've gone a long time from actually using npm proper. Like, the public npm registry. And I had seen the yarn npm registry (mirror?). I'm like...
"that's cool, but how can they stay in sync? like, a publish to yarn isn't going to make it into npm, because npm doesn't read from yarn."
So in no future world will some exclusive "yarn only" ecosystem evolve, where collaborations of npm packages exclusively state that, you know, you can't install stuff unless you use the yarn registry.
So yarn is never going to become an alternate or a competitor to npm. Which feels weird to me. Are we stuck with npm forever?
Anyway. What does this have to do with provenance?
It's the "built from source" idea. The same idea that F-Droid uses.
Let't put on the black hat for a moment.
Look, a npm package can post a link to a source control repo, whatever repo it wants to. Npm doesn't check this.
And that source control repo might match the package and its version history, like with tags and releases. But, npm's flaw is that it just lets a package author upload whatever he wants to.
Npm isn't building your packages for you, or checking that the built bundle is correctly built from your source code. That'd be pretty much offering free compute power with a free CI build check.
Recently, npm has had a "beta" file explorer for the package's files. You could go in and inspect the files that are in npm's public version of the package. So that's a security measure: that attacks are publicly visible.
But who does that? Who reads the source code? Then minify it! Everybody will pass over it.
But, security researchers... there are probably people who have written scripts that build github repos and compare their output to their public npm packages, to detect malicious publishing. I mean, maybe this is a normal part of being a security researcher. Sorry if I'm sharing the alpha.
But it's not enough... I could do this attack. I'm a small fish, and it'd probably get me immediately blocked and banned for life (sorry to my ~8 monthly installs; it's been a great ride). Humor aside -- it's an attack that could happen before it gets caught. And that is not a secure system, to me.
I am a small fish, and so I know that, no matter how good my packages are, nobody is ever going to use them. (My AI complimented them one time, but that's probably going to be my peak.) But, in the off-chance that an enlightened soul would see and decide to depend on one of my packages -- they better to hell be able to trust the package and not consider it to be a liability. Provenance is part of that.
Provenance is a clear signal that I don't want -- no, I can't -- do this attack. Because I don't build the packages. GitHub does. And their agents sent along this nice little metadata record that's stamped by them, saying "this git commit and this workflow script produced this npm package". And npm displays that as a badge.
It's a really neat integration. (Well, when it worked)
So, unless a GitHub insider and I collude to tamper with a provenance certificate, it means that the package you're getting is the package that is in the source code. Unless npm is colluding also but yk we can't just go through all of the risk areas...
Anyway, building from source with provenance is a great model, but it's hard to understand, and hard to implement. Sort of like this article. (Why are you still here?). But if you can get through it all, then provenance is a mark of honor.
I should write another article about the technical implementation of provenance using github actions. Hopefully soon.
Top comments (0)