Comment by vsgherzi
25 days ago
Not to beat a dead horse but I see this again and again with dependencies. Each time I get more worried that the same will happen with rust. I understand the fat std library approach won’t work but I really still want a good solution where I can trust packages to be safe and high quality.
If the fat std library is not viable you can only increase security requirements.
Axios has like 100M downloads per week. A couple of people with MFA should have to approve changes before it gets published.
This is the actual answer: stupid cost saving creating an operational risk.
At least then they will have to pay off a dev or something, changes their economic calculus and is additionally illegal
Hosting curated dependencies is a commercially valuable service. Eventually an economy arises where people pay vendors to vet packages.
Linux distros and BSD ports did that since the 90's. When Linux distros had barely a PM or just tarballs, Infomagic sold 4 CD full of libre software. When I had no internet at home, back in the day I bought 3 DVD's of Debian Sarge for 20 euros, about $20. A bargain, it was the price of a hard-cover best seller book.
GB's of libre software, graphical install, 2.6 kernel, KDE3 desktop, very light on my Athlon 2000 with 256MB of RAM. It was incredible compared to what you got with Windows XP and 120 Euro per seat. Nonfree software and almost empty.
And, well, if for instance I could get read only, ~16TB durable USB drive with tons of Guix packages offline (in a two yearly basis with stable releases) for $200 I would buy them in the spot.
You would say that $200 for a distro it's expensive, but for what it provides, if you are only interested in libre gaming and tools, they amount you save can be huge. I've seen people spend $400 in Steam games because of the Holyday sales...
It's what linux distributions do.
Queue appimage or other packed binary and there go your finetuned packages.
2 replies →
It already exists; cloudsmith
Why wouldn't the "fat std" thing work? Yes it's hard to design properly, both in scope and actual design (especially for an unstandardized language still moving fast), but throwing the towel and punting the problem to the "free market" of uncurated public repos is even worse.
It's what we call in France "la fête du slip".
PS: that's one reason I try to use git submodules in my Common Lisp projects instead of QuickLisp, because I really see the size of my deptree this way.
Fat std library mistakes/warts would likely result in third party packages being used anyway.
Not necessarily, but let's agree that some design faults would happen: you still get the option to use the solid, boring and slightly rusty std instead of another 100 dependencies from the supply chain supermarket.
At work, we're happy with Python's included batteries when we need to make scripts instead of large programs.
So it provides another option, and in worst case it doesn't make situation worse than it is right now?
Yeah, pretty bad idea.
Because fat std is rigid, impractical, and annoying.
In practice (e.g. Go) it’s actually pretty good and infinitely preferable to third party everything.
Yeah, it's annoying to have good support for dates in Java since 2014, instead of only getting it now like in JS.
Works just fine in Go.
I think we found the constituency that led to the present sorry situation.
1 reply →
NPM should have a curation mechanism, via staff review or crowdsourcing, where versions of popular packages are promoted to a stable set, like linux distros do. I would only use curated versions if they had such a thing.
An alternative:
- copy the dependencies' tests into your own tests
- copy the code in to your codebase as a library using the same review process you would for code from your own team
- treat updates to the library in the same way you would for updates to your own code
Apparently, this extra work will now not be a problem, because we have AI making us 10x more efficient. To be honest, even without AI, we should've been doing this from the start, even if I understand why we haven't. The excuses are starting to wear thin though.
Just going to put features on hold for a month while I review the latest changes to ffmpeg.
As you should. Also, the constant complaint from devs on these very boards is that quality and security are relegated behind new features that are often described as useless but pushed by management.
Are you in management?
I don't know where you've worked but a hostile and intelligent actor or internal red team would succeed under each of those cases at every job I've worked at.
Good to know. Where were the places you worked at?
Defending against a targeted attack is difficult, yes. But these recent campaigns were all directed at everyone. Auditing and inspecting your dependencies does absolutely help thwart that because there will always be people who don't.
They succeeded in poisoning the whole supply chain and making everyone distrust package management to a degree never seen before, and people who aren't reviewing their dependencies are already getting hit. You seem to suggest that we all accept that.
That attitude might be the reason why the places you've worked would be under threat. The places I've worked would also be under threat, because several of my colleagues had that attitude, and this is why red teaming works.