[reactordev]

Until you go get malware

Supply chain attacks happen at every layer where there is package management or a vector onto the machine or into the code.

What NPM should do if they really give a shit is start requiring 2FA to publish. Require a scan prior to publish. Sign the package with hard keys and signature. Verify all packages installed match signatures. Semver matching isn’t enough. CRC checks aren’t enough. This has to be baked into packages and package management.

[lycopodiopsida]

> Until you go get malware

While technically true, I have yet to see Go projects importing thousands of dependencies. They may certainly exist, but are absolutely not the rule. JS projects, however...

We have to realize, that while supply chain attacks can happen everywhere, the best mitigations are development culture and solid standard library - looking at you, cargo.

I am a JS developer by trade and I think that this ecosystem is doomed. I absolutely avoid even installing node on my private machine.

[homebrewer]

Here's an example off the top of my mind:

https://github.com/go-gitea/gitea/blob/main/go.sum

[EdiX]

I think you are reading that wrong, go.sum isn't a list of dependencies it's a list of checksums for modules that were, at some point, used by this module. All those different versions of the same module listed there, they aren't all dependencies, at most one of them is.

Assuming 'go mod tidy' is periodically run go.mod should contain all dependencies (which in this case seems to be shy of 300, still a lot).

[mayama]

Half of go.sum dependencies generally are multiple versions of same package. 400 still a lot, but a huge project like gitea might need them I guess.

> cat go.sum |awk '{print $1}' | sort |uniq |wc -l

431

> wc -l go.sum

1156 go.sum

[HillRat]

Sign the package with hard keys and signature.

That's really the core issue. Developer-signed packages (npm's current attack model is "Eve doing a man-in-the-middle attack between npm and you," which is not exactly the most common threat here) and a transparent key registry should be minimal kit for any package manager, even though all, or at least practically all, the ecosystems are bereft of that. Hardening API surfaces with additional MFA isn't enough; you have to divorce "API authentication" from "cryptographic authentication" so that compromising one doesn't affect the other.

[Hackbraten]

How are users supposed to build and maintain a trust store?

In a hypothetical scenario where npm supports signed packages, let's say the user is in the middle of installing the latest signed left-pad. Suddenly, npm prints a warning that says the identity used to sign the package is not in the user's local database of trusted identities.

What exactly is the user supposed to do in response to this warning?

[biggusdickus69]

This is a solved problem. https://en.wikipedia.org/wiki/Web_of_trust

[Hackbraten]

Imagine a hobbyist developer with a ~ $0 budget trying to publish their first package. How many thousands of km/miles are you expecting them to travel so they can get enough vouches for their package to be useful for even a single person?

Now imagine you're another developer who needs to install a specific NPM package published by someone overseas who has zero vouches by anyone in your web of trust. What exactly are you going to do?

In reality, forcing package publishers to sign packages would achieve absolutely nothing. 99.99 % of package consumers would not even bother to even begin building a web of trust, and just blindly trust any signature.

The remaining 0.01 % who actually try are either going to fail to gain any meaningful access to a WoT, or they're going to learn that most identities of package publishers are completely unreachable via any WoT whatsoever.

[rs999gti]

> What NPM should do if they really give a shit is start requiring 2FA to publish.

How does 2FA prevent malware? Anyone can get a phone number to receive a text or add an authenticator to their phone.

I would argue a subscrption model for 1 EUR/month would be better. The money received could pay for certification of packages and the credit card on file can leverage the security of the payments system.

[psychoslave]

How will multi-factor-authentication prevent such a supply chain issue?

That is, if some attacker create some dummy trivial but convenient package and 2 years latter half the package hub depends on it somehow, the attacker will just use its legit credential to pown everyone and its dog. This is not even about stilling credentials. It’s a cultural issue with bare blind trust to use blank check without even any expiry date.

https://en.wikipedia.org/wiki/Trust,_but_verify

[deanc]

That's an entirely different issue compared to what we're seeing here. If an attacker rug-pulls of course there is nothing that can be done about that other than security scanning. Arguably some kind of package security scanning is a core-service that a lot of organisations would not think twice about paying npm for.

[cesarb]

> If an attacker rug-pulls of course there is nothing that can be done about that other than security scanning.

As another subthread mentioned (https://news.ycombinator.com/item?id=45261303), there is something which can be done: auditing of new packages or versions, by a third party, before they're used. Even doing a simple diff between the previous version and the current version before running anything within the package would already help.

[cxr]

If NPM really cared, they'd stop recommending people use their poorly designed version control system that relies on late-fetching third-party components required by the build step, and they'd advise people to pick a reliable and robust VCS like Git for tracking/storing/retrieving source code objects and stick to that. This will never happen.

NPM has also been sending out nag emails for the last 2+ years about 2FA. If anything, that constituted an assist in the attack on the Junon account that we saw a couple weeks ago.

[ptx]

NPM lock files seem to include hashes for integrity checking, so as long as you check the lock file into the VCS, what's the difference?

[cxr]

Wrong question; NPM isn't bedrock. The question to be answered if there is no difference is, "In that case, why bother with NPM?"

[floydnoel]

NPM does require 2FA to publish. I would love a workaround! Isn't it funny that even here on HN, misinformation is constantly being spread?

[cxr]

NPM does not require two-factor authentication. If two-factor authentication is enabled for your account and you wish to disable it, this explains how to do that if allowed by your organization:

<https://docs.npmjs.com/configuring-two-factor-authentication...>

[bakkoting]

It doesn't require 2FA in general, but it does for people with publish rights for popular packages, which covers most or all of the recent security incidents.

https://github.blog/changelog/2022-11-01-high-impact-package...

[olejorgenb]

> The malware includes a self-propagation mechanism through the NpmModule.updatePackage function. This function queries the NPM registry API to fetch up to 20 packages owned by the maintainer, then force-publishes patches to these packages.

[yawaramin]

npm offers 2FA but it doesn't really advertise that it has a phishing-resistant 2FA (security keys, aka passkeys, aka WebAuthn) available and just happily lets you go ahead and use a very phishable OTP if you want. I place much of the blame for publishers getting phished on npm.