111–120 of 221 posts
Earlier quoted context omitted.
> they fired many staff engineers Would you rather the company went under after it ran out of money and had to fire everyone instead? Not to mention a quarter of the company was laid off the year before the acquisition.
Was that the case? Can you provide sources to your claims and provide a foundation to your theories?
Earlier quoted context omitted.
No, and that's why we must destroy them. Figuratively then literally.
Destroy what exactly? And replace with what?
Earlier quoted context omitted.
I don't think it'd necessarily be a good decision, sometimes CVE are actively exploited and need quick patching. A better safety net would be to require active 2FA proof for every package update.
If you need a quick patch, you pass another parameter to turn off the 1 day. 1 day delay will prevent more problems than it makes.
Have you rolled the numbers, vs all of the high-pri security updates that will be missed on day one, and exploited?
What is really needed is simply more nuance. I agree the delay can help, but honestly the entire ecosystem is broken. There shouldn't be a single thing installed, without someone having an eyes-on. That's how this is fixed.
Distros aren't perfect, but they handle this a load better. And this really runs to the problem, people want "new new new", yet often have very little real reason to want it. 99% of npm packages could be 5 years old, and no one would care.
But outside of that, npm could operate like a distro, but with more of a Debian unstable -> testing method, where it typically takes a few days for this migration to happen.
My point is, the fix isn't publishing by default, then hoping to catch. The fix is that nothing gets published, without a QA/validation step. Of course, that takes money. There is naturally, a super easy fix for that.
The code stays open source. The licensing stays . However?
The ToS for using any or all of the npm architecture is if you're a company, you pay. If you neglect to pay, eg you don't register as a corporate entity, set up and account, and pay per use, then as per ToS the licensing is invalid, and you're fined via a copyright infringement. And yes, this would mean all npm packages would have an altered licensing model, basically with this tacked on.
Is what I'm saying perfect? Nope. Yet it's the general path which should be taken. And frankly, with the way things are going, this level of audit would allow for staff also categorize licenses, ensure accurate template files, and so on.
And some of this is the perfect use of an LLM. Not to do the work, but to flag with human review.
--
This ecosystem is done. Its model is broken. The concept of downloading random stuff without auditing in any way, is broken. The industry will be moving away, is starting to move away, and is having to move away.
So... how can this survive with that concept?
If one doesn't like my proposal above, then they should provide an alterative which allows:
* companies to have validate of licensing * audits which validate change is not untoward
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…
Having a non-script method of downloading the right native binary would be a good next step.
Looks good? But doesn't this just change the compromise window from first installation to first run?
Ok? Not sure what a package manager can do about the fact that eventually you want to run the things you install.
They should have added a 1-day age limit by default, so security scanners have some time.
https://red.anthropic.com/2026/n-days/
So that is a poor bandaid to use now. Maybe instead validate things before, and have more of a cathedral and human reputation system.
I wonder if there are still reasons to use yarn? Has yarn also implemented safeguards to protect against supply chain attacks? Until now, I only knew about pnpm. It’s great that npm has followed up.