Live data from Hacker News

Upcoming breaking changes for npm v12

github.blog

201–210 of 221 posts

Re: Upcoming breaking changes for npm v12

#201
post #93
post #46

I bet there have been a hundred different discussions about this inside of NPM since it was disclosed 10 years ago. With Shai Halud it's gotten too big to ignore.

I do love that javascript's history is basically just coder mentality distilled. "oh yeah we'll fix that shortly" is almost always "oh fuck now we have to"

A different framing would be things moving from a high-trust equilibrium to a low-trust one due to a few bad actors and no other way to stop their activities.

Security part reasonable code robustness, part Red Queen's race. Attackers expend ongoing effort for new exploits, defenders expend ongoing effort to get back into a secure place, everyone ending up where they started.

If world were a nicer place we wouldn't have to "fix that shortly".

Re: Upcoming breaking changes for npm v12

#202
post #157

Earlier quoted context omitted.

Nothing in there suggests that this was done to save the company from bankruptcy, which was the wild claim.

No one said anything about bankruptcy, you seem to have made that up for your "argument" or whatever this is. The company didn't have a viable business model and was running out of cash. MSFT right-sized the team for the project they wanted it to be, rather than the business model the prior company was trying to be.

Learn to read

> Would you rather the company went under after it ran out of money and had to fire everyone instead?

Re: Upcoming breaking changes for npm v12

#204
post #137

Earlier quoted context omitted.

We already have alternative and superior proposals, it's called Deno. It's node + npm compatible and its permission system locks everything down by default. If you know ahead of time, you can turn on which permissions something is supposed to have in the config file. Or you can just not use a config file at all. Anytime it needs a permission: it asks you what it wants. You can say yes or no, and those are saved in th…

Can you clarify why the node permission system is broken but the deno one works? For an outsider like me both look like the same.

Deno's permissions are closed by default.

Node's permissions are open by default.

---

Let's suppose that node and deno both have the same 20 permissions.

If we have a project that needs read access to one specific folder and write access to another specific folder, that means:

For deno: I need to turn on 2 permissions to those folders. For node: I need to go through all 18 other permissions to turn them off, and also turn 2 permissions to access only those folders.

So from the get go, node is more work.

---

We're all lazy creatures.

We might forget to turn off the permissions, or worse: think we're safe because we only turned off what we thought were the relevant permissions.

Example:

My project reads this folder and writes to this other folder, I'll turn off the network permission so my data can't be exfiltrated, and commands can't come in down the wire if a dependency becomes part of an attack. And because I'm smart, I'll also turn off the FFI permission so a dependency can't communicate with a program outside of node.

Safe right?

No. The hacker took over a dependency and called cURL through a new process.

There's a million ways to go around things with an open-by-default security model.

Open-by-default is a broken design from the start.

It's a lesson that's been learned over and over again.

A closed-by-default security model is the only way.

---

Deno uses a closed-by-default security model, and implements it in a way that isn't annoying. It just runs your program immediately then when it tries to call a function that requires a permission that it doesn't have, it doesn't crash, instead it pauses execution and asks if it can have that permission. If you say yes, it remembers and doesn't bother you again, if you say no, then the function throws an error to be caught by your code or to bubble up uncaught and crash the program to prevent anything not permitted by you taking place.

The other great thing about it, is that you can run something on deno instead of node, and see which permissions it asks you for.

You'd be surprised how not safe some things are. Once you try it on a few example projects, you'll instantly see why npm has so many hacking incidents. It's an eye-opening anxiety raising experience.

On the other hand, when you run a project and see basically no requests for permissions, you can feel a sense of relief that it can only do what it says on the tin.

Re: Upcoming breaking changes for npm v12

#205
post #68

Earlier quoted context omitted.

native modules. nodejs can have native modules (written in C++, Rust, etc...). Projects usually ship prebuilt natives binaries (for each arch/OS/Nodejs ABI combination) hosted on GitHub Releases and download them automatically at installation time; fallback to build from source if not found. that's where scripts are used the reason for not bundling all native binaries is becasue the no. of combinations are huge and i…

This used to be more common but the pattern these days is to have the binaries split into optionalDependencies which declare their supported CPU etc, one per supported platform. Then npm will install just the matching one (optionalDependencies that require a different platform aren't installed). The fact that most of the ecosystem has moved to this pattern is a big part of why this change is now feasible.

that's why. for those who want to read more about this, napi-rs support this natively

https://napi.rs/docs/deep-dive/release

Re: Upcoming breaking changes for npm v12

#206

I'm not sure how I missed that npm was acquired by GitHub, but man, a lot of stuff suddenly makes a lot of sense. I really can't think of a worse home for such a critical part of the Node ecosystem.

As someone who used npm since at least 2014, it was already fucked before Microsoft (who owns GitHub) got there to make things worse. That's why yarn and pnpm and bun and a few lesser knowns exist.

Re: Upcoming breaking changes for npm v12

#207

I'm not sure how I missed that npm was acquired by GitHub, but man, a lot of stuff suddenly makes a lot of sense. I really can't think of a worse home for such a critical part of the Node ecosystem.

Eh, it was pretty terrible before the acquisition too...

It's way less shitty now. Though one could kill a couple beers just complaining about how many major node versions it took before it wasn't shitty.

Re: Upcoming breaking changes for npm v12

#208
post #122

postinstall scripts should've been removed long time ago, it's the cancer of NPM packages. There's so many deeply nested, uncontrolled postinstalls that run randomly when you pull something it's insane, I don't know how someone at some point ever though that was a good idea.

On a project with a 1GB node_modules directory (after aggressive cleanup) I think we only had one dependency that didn't work right with postinstall disabled. Though I can't recall which and I don't work there anymore so I can't hunt.

And IIRC that one was fixable by a PR, because they'd done something weird and there was an idiomatic way to accomplish the same thing.

Re: Upcoming breaking changes for npm v12

#209
post #108
post #56

Earlier quoted context omitted.

Young people thought M$ was changing, the old folks knew it was just another cycle of embrace, extend, extinguish.

The ruthlessness of the Microsoft that we remember was probably due to influence from Bill Gates. He is famous for hyper-competitiveness and strong desire to win at all costs.

Yeah but I worked with enough ex MS employees to know that Bill built a cult. Cults don't die just because the cult leader retires to go buy his way into heaven.

Re: Upcoming breaking changes for npm v12

#210
post #38

didn't know npm was owned by github.. well, that explains things...

NPM (the company) was about to go under in 2020. They raised VC but never found a sustainable business model. GitHub acquired them to keep the ecosystem alive. The acquisition hasn't really benefitted GitHub much at all.

No there are gobs of node projects on GitHub. I'm sure someone did the math on how many paying customers would have been fucked if npm.org went away and it worked as a loss leader.
Post reply on HN