Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

That is insane that any company allowed this to happen.

""That said, we consider the root cause of this issue to be a design flaw (rather than a bug) in package managers that can be addressed only through reconfiguration," a Microsoft spokesperson said in the email."

No, npm has scopes for a reason, why would that not fix this issue?



Probably, it's more fun to play with syscall filtering in containers or with fuzzers than to review side-channels or educating coworkers. Therefore, security theater.


Isn't it considered best practice to be secure by default? Wasn't that big fiasco with MongoDB? Why should PyPI, RubyGems, or npm be any different? I'm sure there is some reason but I'd expect them to all pull private repos before public.

Maybe the bug wasn't explained correctly but if it prefers public over private that seems like a bug.

OTOH, it certainly is an issue that if you forget and happen to test some code without being configured to have the private package server as your default then you'd get public repos.

Maybe instead of named packages companies should be using private URLs for packages. That way you always get what you ask for?


npm does not have any 'private package' functionality at all, instead you point it at a different registry server (using eg. Verdaccio or Artifactory) which then serves local packages and proxies public packages if they don't exist locally - or at least that's what they're supposed to do.

Artifactory apparently didn't, and served up whichever was the highest version of public vs. private. Which is stupid.

But the bottom line is that when using npm, the exact package selection policy is determined by whatever registry implementation you're talking to, and so it's the registry implementation which should prioritize private packages by default.


Scopes were only introduced in NPM 2, and iirc it's still an optional feature. Companies that used NPM early on may have opted to never use those.

But that's just NPM, it's an issue in all of the mentioned package managers.


true. simplest solution is just always prioritize internal over external.


Just "prioritizing" doesn't fix it, you have to limit scoped packages to be provided by a single (trusted, internal) repo. Otherwise, what do you do when internal offers v1.2.3 but external says it has v1.99.99?


This is exactly what Verdaccio does, and has been doing since forever. It frankly kind of boggles my mind that other private registry implementations don't.


Automatic updates from poor sources is probably a bad idea anyways... whether they prioritize local packages or not. (I.E.: Play Store, PyPy, etc...)


GitHub could provide a default merge rule to prevent this attack




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: