Live data from Hacker News

Malicious npm packages detected across Red Hat Cloud Services

github.com

491–494 of 494 posts

Re: Malicious npm packages detected across Red Hat Cloud Services

#491

Earlier quoted context omitted.

Regardless of what these attacks exploit, see elsewhere a larping comment of mine: the solution exists, the implementation already mitigated numerous such and other exploits (it's nice to read "nix is not affected" on discourse or over matrix chat), it predates Docker by a decade, and is older than Ubuntu and Fedora (to give the perspective), yet people prefer to remain ignorant.

You can have a security solution but with large ecosystems like this it can’t be pushed to the ecosystem immediately and everyone will take longer to test and deploy. Right now you could audit packages and make sure you don’t get the latest version

That's bullshit and shows you don't understand nixpkgs model.

Re: Malicious npm packages detected across Red Hat Cloud Services

#492
post #478

Earlier quoted context omitted.

Caching proxies are a decent middle ground like Artifactory. AWS might support that (maybe only on certain repo types?) Generally you can also configure rules in your internal package cache about what to do if a package is missing from the cache/hasn't been pulled yet. They also commonly integrate automaticaly CVE tracking and pull statistics so they give a nice "heads up" what everyone is using even if it's a local…

or you can throw all of this into the trash and just use Nix.

The parent is about vendoring dependencies which Nix does not do by default so that is not a solution here.

Re: Malicious npm packages detected across Red Hat Cloud Services

#493

Hope it's ok I hijack this thread again about setting up cooldowns... (copy pasting my last comment when tanstack was compromised): I know people have opinions about cooldowns, but they would have saved you from axios, tanstack, (+ @redhat-cloud-services) and many other recent npm supply chain attacks. If you have Artifactory / Nexus, you probably already have cooldowns, but it's easy to set up if you don't. Why cool…

> Hope it's ok I hijack this thread again about setting up cooldowns... In addition to cooldowns it'd be nice if more package managers did triage between security fixes and normal releases (bug fix / performance improvement / new functionalities). It's totally possible to say: "A security fix must only be a security fix and cannot ship any other feature" . Then, for a start, a security fix becomes easier to audit (bo…

> no cooldown (or a much smaller countdown) for security fixes.

A supply chain attack would likely able to publish a "security" release just as easily as a normal release, so I don't think that would help much.

Re: Malicious npm packages detected across Red Hat Cloud Services

#494

Earlier quoted context omitted.

> 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…

That group of people is the loosely affiliated people called "vibe coders". Even to get them to install depsguard is a challenge. I just ask them to point Claude to depsguard or cooldowns and follow the instructions (to save the tokens, of course Claude can figure it what needs to be done on its own) The issue is that Claude Code also will be super happy to npm install axios / tanstack etc unless you explicitly tell…

Ha. Yes I haven't calibrated myself well for that form of users. It would seem that telling them to tell their agent to read cooldowns might be the best advice there; they sure as he'll won't read it.
Post reply on HN