131–140 of 235 posts
Earlier quoted context omitted.
Absolutely agreed on the lack of documentation, it seems completely insane (I assume this is because they want to reinforce that only Apple should be writing policies - but still no excuse for it) >Hard to recommend it with that axe hanging over it though. Given the alternative being no way to limit untrusted tooling at all today, it seems worthwhile using it despite these problems? There's also a (very slim) chance…
Yes definitely worth using it, but I don't know how much time I want to spend integrating it deeply into my own open source projects given its uncertain status.
0: https://chromium.googlesource.com/chromium/src/+/refs/heads/...
Question for tanepiper: what would you have Microsoft do to improve things here? My read of your article is that you don't like postinstall scripts and npx. I'm not convinced that removing those would have a particularly major impact on supply chain attacks. The nature of npm is that it distributes code that is then executed. Even without npx, an attacker could still release an updated package which, when executed as…
Exactly. The biggest problem with npm is that it is too popular. Nothing else. Even if you "mitigate" some of the risks by removing features like postinstall, it barely does anything at all -- if you actually use the package in any way, the threat is still there. And most of what we see recently could happen to crates.io, pypi etc as well. It is almost frustrating to see people who don't understand security talk abou…
Npm could add this as an automated step during publishing. Sure, there's a manual review needed for anything flagged, but you can easily fix this as well by having smth like a trusted contributor program where let's say you'd need 5 votes to overrule a package being flagged as malware
Earlier quoted context omitted.
Deeply underrated comment. You can peel back the layers of sarcasm like... An onion.
Btw, it's copypasta at this stage
https://duckduckgo.com/?q=site%3Atheonion.com+%22no+way+to+p...
Earlier quoted context omitted.
Sidestep this debate with one trick - use the GPLv3. No company large enough to have a legal team will be able to use it, you're still squarely within the various definitions, and the FSF basically has to approve. As a bonus maybe you can get some proprietary software open sourced too.
Is there a real reason not to use AGPL? The fact that it makes Google very uncomfortable[1] is a great selling point to me. [1]: https://opensource.google/documentation/reference/using/agpl...
Earlier quoted context omitted.
I’ve contributed a huge amount of opensource code over my career - almost all of it entirely unpaid. I don’t know the statistics, but I know many other people who have done the same. I think there are a lot of high profile opensource projects which are either run by corpos (like React) or have a lot of full time employees submitting code (Linux). But there’s an insanely long tail of opensource projects on npm, cargo,…
npm was a company for years now. It was initially created as a volunteer one person project, then they create company 10 years ago and eventually sold to Github which was sold to Microsoft. It has spent more time being developed as a paid thing then by unpaid volunteers doing it on the side.
I think the cooldown approach would make this type of attack have practically no impact anymore, if nobody ever updates to a newly published package version until, say, 2-3 days have gone by, surely there will be enough time for owner of the package to notice he got pwnd.
https://docs.renovatebot.com/configuration-options/#minimumr...
Here’s a one-liner for node devs on MacOS, pin your versions and manually update your supply chain until your tooling supports supply chain vetting, or at least some level of protection against instantly-updated malicious upstream packages. Would love to see some default-secure package management / repo options. Even a 24 hour delayed mirror would be better than than what we have today. find . -name package.json -not…
? Package lock files from npm/yarn/pnpm automatically lock all your dependencies (including transitive deps) What does this actually achieve?
Whether that's so important, I'm not sure.
"No Way To Prevent This" Says Only Package Manager Where This Regularly Happens
This is funny but ultimately a mischaracterization of a popularity contest. Node culture is extreme–perhaps pathological–about using many dependencies to work around the limited standard library but the same kind of attacks happen everywhere people are releasing code. The underlying problem is that once you release something it takes only seconds before someone else can be running your code with full privileges to ac…
It's literally just a joke. If it tickles your fancy, it works for you. If you get lost in the weeds of comparing the socio-political mechanisms of open source to guns, or note that supply chain attacks happen to other package managers, the joke won't work for you.
I assure you, it works just fine for me even though yes I think it would be ridiculous to claim there's anything more to the comparison than, "This thing keeps happening, nobody thinks doing anything about it is worth the bother, so look at that, it keeps happening."