351–360 of 494 posts
Earlier quoted context omitted.
Yes, none of npm's lifecycle hooks. You're just pulling bytes over the wire.
Except now you're making http calls to remote servers that could be compromised.
There's plenty of comments mentioning delay lines, and the other good stuff pnpm (and others) have implemented in response to protect package consumers.
That bit that's getting less conversation is the tools on the package maintainer side:
- MFA for publishing: https://docs.npmjs.com/requiring-2fa-for-package-publishing-...
- trusted publishers, available for about a year: https://docs.npmjs.com/trusted-publishers
And as of recently, staged publishing, essentially combining the best of both those features: https://docs.npmjs.com/staged-publishing
Now you can: - Publish from CI, without static credentials
- AND require a maintainer to approve it using MFA before it actually goes live to the registry
If you want you can still use something like GitHub Actions Environments protection to require multiple approvals, or a time delay, on the CI side.
We need to encourage the community to adopt these publishing protections or this will continue to be an issue.
Earlier quoted context omitted.
The problem is compounded with NPM though thanks to lifecycle scripts: yes, any and all package managers create a risk of supply-chain attack, but NPM makes it dangerous to merely open a project up in an IDE.
That's a good point. For me it's getting people to realize they need to take up practice that help minimize these things. It's kinda us and them problem. We need to ensure we don't just blindly install the latest, patch every CVE by just bumping everything to the latest even if the vulnerability has nothing to do with their system or use of said library. We should have rules that we install the latest that's older th…
The three day 'rule' is just you hoping that someone else does some free work for you. If it is adopted by everyone, it has zero effect.
We need rules that still work if people follow them.
Earlier quoted context omitted.
It's not that there isn't a conversation to be had. It's that it's a low-effort, karma farming, reddit-tier comment that always invites emotional/reactionary responses, typically the same ones as before, that usually shoots to the top of the comments section and drowns out any relevant or interesting (see: curious, as per HN guidelines) discussion.
[flagged]
Earlier quoted context omitted.
Should we instead of these cooldowns just run builds in isolated contexts? I’m running a maven proxy locally. All builds happen inside containers. I only use public repos for python, npm, and go. So these builds happen also in containers but don’t need a repository proxy.
> Should we instead of these cooldowns just run builds in isolated contexts? I'd suggest both. Cooldown for 1-2 days is very cheap and you likely won't even notice it, so it's quite harmless and from what I've seen even just 24 hours is enough to let security companies pick up malware. But yeah, isolation is a must-have.
Or as us or companies to wrap the build tools to provide the wrapping for them.
In every of these threads there's a bunch of snarky comments, either acting like this class of attack is exclusive to npm, or that nothing has been done about it. I don't think that's fair. There's plenty of comments mentioning delay lines, and the other good stuff pnpm (and others) have implemented in response to protect package consumers. That bit that's getting less conversation is the tools on the package maintai…
In every of these threads there's a bunch of snarky comments, either acting like this class of attack is exclusive to npm, or that nothing has been done about it. I don't think that's fair. There's plenty of comments mentioning delay lines, and the other good stuff pnpm (and others) have implemented in response to protect package consumers. That bit that's getting less conversation is the tools on the package maintai…
The bug here isn't that we need to better authenticate already-trusted upstreams for packages, it's that the upstreams cannot be trusted as the sole source for security at all. Upstreams are a bunch of hackers[1] who aren't really interested in, nor will ever be good at, solid release engineering practices.
But some people are! The solution in the Linux world (and the one that saved us from xz-utils) is that there is a second level of human beings responsible for reviewing, auditing, packaging, and customizing those hacker-generated upstreams for the benefit of their users. These people have different eyes, different consumer requirements and different quality metrics. And they catch bugs and malfesance that the upstreams aren't prepared to do.
NPM (and cargo/PyPI et. al.) continues to think it can short circuit this requirement for human labor. It can't.
[1] In NPM's particular ecosystem, a bunch of web jockeys used to extremely fast release processes, loose compatibility requirements, and extreme reliance on reuse. This really explains why we see this with node packages more than Python or Rust: older and more conservative programmers just don't have as many rakes to step on.
Earlier quoted context omitted.
I wish that was the case. Asking people to do something simple, doesn't matter how simple it is, depends on how simple they view it. Changing your own car's oil is actually not that hard, once you know how to do it, most people don't even try. Think of QR codes, people hardly used them for many years, because you needed to download an app for it, small step. It only started to catch up when you had it built in the ca…
> Changing your own car's oil is actually not that hard It is. Changing oil requires a place where you have sufficient access to the vehicle to drain it; the right equipment; the right disposal solutions. Most people who have cars do not have that. And it takes significantly more time to change your own oil than to have someone else do it as part of other specialist maintenance. > Think of QR codes, people hardly use…
> a place where you have sufficient access to the vehicle to drain it
Probably the only valid argument for people who park on the street.
> the right equipment
One $5 wrench, one $10 filter wrench (optional). One set of ramps ($40), or jack stands ($30) if you already have a jack. One drain pan, $10 (or free if you're resourceful). Total cost max $65. Cheaper if you look for deals, buy used, borrow from a friend. If you can't afford $65 once to save money in the long run while owning a car, you probably should've bought a cheaper car.
> the right disposal solutions
Every oil change requires a jug of oil to be purchased. You can drain your used oil into this jug and then dispose of it along with your other household hazardous waste. This is not hard.
> Most people who have cars do not have that.
I might believe this for a place to do an oil change, maybe. I struggle to believe most, but I would believe many. Aside from that, if you don't have those things, you are choosing not to have them.
Which is kind of the point. None of these things are hard, at all. The majority of car owners 100 years ago could adjust their own timing, clean distributor points, replace belts, etc. because if they couldn't, they'd be calling for a tow truck every few hundred miles. Those are all harder, and things have only gotten easier with time. If you can't do them, you are choosing not to, because there's an even easier solution - spending more money and getting someone else to do it for you.
Earlier quoted context omitted.
That's a good point. For me it's getting people to realize they need to take up practice that help minimize these things. It's kinda us and them problem. We need to ensure we don't just blindly install the latest, patch every CVE by just bumping everything to the latest even if the vulnerability has nothing to do with their system or use of said library. We should have rules that we install the latest that's older th…
> The three day rule alone could save most people. The three day 'rule' is just you hoping that someone else does some free work for you. If it is adopted by everyone, it has zero effect. We need rules that still work if people follow them.
Earlier quoted context omitted.
MS Nuget is also lock-by-default. Latest-by-default should be considered harmful unless the package manager is directly vouching for the veracity and reputability of the packages.
NuGet is lock-by-default for the parent package, but with the move from packages.config to it's no longer lock-by-default for dependencies.