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 3 hours ago | parent | next [-]

> 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 3 hours ago | parent [-]

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

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

	▲	EdiX 3 hours ago \| parent \| next [-]
		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 3 hours ago \| parent \| prev [-]
		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

▲

rs999gti an hour ago | parent | prev | next [-]

> 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 3 hours ago | parent | prev | next [-]

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 2 hours ago | parent [-]

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 an hour ago \| parent [-]
		> 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.

▲

HillRat 2 hours ago | parent | prev | next [-]

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.

▲

cxr 3 hours ago | parent | prev | next [-]

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 3 hours ago | parent [-]

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 2 hours ago \| parent [-]
		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 3 hours ago | parent | prev [-]

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 2 hours ago \| parent [-]
		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...>