Hacker News Reader

Comment by tcd | Hacker News Reader

It's hilarious, after the event-stream fiasco last year, NPM has changed...Nothing. NodeJS made a 'package maintenance' repo, but failed to address the actual root cause of the problem.

We'll see plenty of other NPM disasters this year, and as always, nothing will change because security is an afterthought not a core mission principle.

If it was, NPM wouldn't exist in its current form. It's confusing, adding extra security wouldn't even be that difficult or time consuming, they just don't.

I wish it were possible to take over a project with individuals who actually care. The people in charge of NPM are incompetent at running a secure, large scale distribution system, why they're still allowed to be a part of it is beyond me...

If security isn't your top goal you don't belong in charge of a very important, widely used ecosystem which many rely on.

View on HN

How do you see secure package management? What extra security would you add?

As I see it people want to use the code third parties control but without trusting them somehow. Package management alone can only go so far. Code just has too much privileges in a language like javascript and no matter what you do something coming from third parties can pwn you or at least facilitate that.

There needs to be a language where code doesn't have so much privileges. Imagine if the language only allowed to import functions that either have no side effects or each side effect required explicit security token, say for reading some file or connecting to some remote host. Instead of passing strings around and let any function have unlimited privileges to read any file, the code would pass security tokens around that let functions only read specified files. Think language level capability-based security. I can't think of anything else that can help with random third party code.

Like Safe Haskell?

Securing a dependency management system like npm, pip, et al is not a solved problem by any stretch. This isn't about the competency of any particular individuals, but the willingness of the software engineering community as a whole to always trade security for speed (of development, of shipping, etc).

NPM announced support for 2FA and read-only tokens soon after the incident.

https://blog.npmjs.org/post/166039777883/protect-your-npm-ac...

Can't say I'm aware of any other package manager even discussing these issues.

Since you said "even discussing", might as well mention that the Rust community has discussed adding 2FA support to cargo: https://internals.rust-lang.org/t/requiring-2fa-to-publish-t.... But as far as I know, crates.io/cargo still has no 2FA feature of its own.

On the other hand, if your crates.io account is linked to a GitHub account, you could have 2FA via GitHub. So I'm not entirely sure whether "cargo supports 2FA" would count as true or false at the moment.

Yes, I'm the author of that thread. It went nowhere.

Obviously this is different than implementing it from scratch, but crates.io (the Rust package repository) does authentication through Github OAuth, which in practice gives you 2FA.

Reply on news.ycombinator.com