←back to thread

1208 points jamesberthoty | 3 comments | | HN request time: 0.401s | source
Show context
codemonkey-zeta ◴[] No.45261026[source]
I'm coming to the unfortunate realizattion that supply chain attacks like this are simply baked into the modern JavaScript ecosystem. Vendoring can mitigate your immediate exposure, but does not solve this problem.

These attacks may just be the final push I needed to take server rendering (without js) more seriously. The HTMX folks convinced me that I can get REALLY far without any JavaScript, and my apps will probably be faster and less janky anyway.

replies(18): >>45261086 #>>45261121 #>>45261140 #>>45261165 #>>45261220 #>>45261265 #>>45261285 #>>45261457 #>>45261571 #>>45261702 #>>45261970 #>>45262601 #>>45262619 #>>45262851 #>>45267210 #>>45268405 #>>45269073 #>>45273081 #
reactordev ◴[] No.45261220[source]
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.

replies(6): >>45261275 #>>45261601 #>>45261616 #>>45261805 #>>45262090 #>>45263276 #
lycopodiopsida ◴[] No.45261275[source]
> 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.

replies(1): >>45261371 #
1. homebrewer ◴[] No.45261371[source]
Here's an example off the top of my mind:

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

replies(2): >>45261541 #>>45261845 #
2. mayama ◴[] No.45261541[source]
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

3. EdiX ◴[] No.45261845[source]
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).