←back to thread

1208 points jamesberthoty | 5 comments | | HN request time: 0.296s | source
1. snickerbockers ◴[] No.45272291[source]
I try to stay as far from web development as possible in my programming career (kernel/drivers and most recently reverse engineering) so maybe I'm ill-informed here but this npm thing seems to be uniquely terrible at security and i cannot fathom why the entire web seems to be automatically downloading updates from it and pushing them into production with no oversight.

I've always worked at companies where we use third party open source libraries utilities and its true that they get less-than-ideal amount of auditing when they get updated but at least we're not constantly pushing updates of to our customers solely for the sake of using the latest version. In fact usually they're out of date by several years which is also a problem but generally there'll be a guy following the mailing lists for updates in case there's a known exploit that needs to be patched.

replies(4): >>45272375 #>>45272654 #>>45274121 #>>45274258 #
2. jefozabuss ◴[] No.45272375[source]
I think all public package registries have this problem as it's not unique to npm.

The "blind" auto updating to latest versions seems to be also an issue here, simply you cannot trust it enough as there is (seemingly) no security vetting process (I mean if you get obfuscated gibberish pushed into a relatively sanely written codebase it should ring some alarms somewhere).

Normally you'd run tests after releasing new versions of your website but you cannot catch these infected parts if they don't directly influence the behavior of your functionality.

3. SCdF ◴[] No.45272654[source]
A lot of it is just that it's at the local maximum of popularity and relative user inexperience, so it's the juiciest target.

But also, npm was very much (like js you could argue) vibed into existence in many ways, eg with the idea of a lock file (eg reproducible builds) _at all_ taking a very long time to take shape.

replies(1): >>45273159 #
4. ricardobeat ◴[] No.45273159[source]
We got lockfiles in 2016 (yarn) and 2017 (npm), before Go, Ruby, and others; I believe python is just getting a lockfile standard approved now.

You could already specify exact versions in your package.json, same as a Gemfile, but reality is that specifying dependencies by major version or “*” was considered best practice, to always have the latest security updates. Separating version ranges from the lock files, and requiring explicit upgrades was a change in that mindset – and mostly driven by containerization rather than security or dev experience.

5. user34283 ◴[] No.45274258[source]
While npm indeed seems most vulnerable, it looks to me like the actual damage done is very small.

Some people had their crypto wallets drained I guess, but as far as I am concerned nothing of any real value was lost.

One could argue that your field saw exploits that did far more damage, no?