Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Malicious npm packages detected across Red Hat Cloud Services

github.com

Post reply on HN
Print view View original

451–460 of 494 posts

Re: Malicious npm packages detected across Red Hat Cloud Services

#451

Post by Grimburger »

jmb99 wrote: post #416
mercurywells wrote: post #386

Earlier quoted context omitted.

Good job, you forgot a new crush washer and now your oil pan will leak

In ~300k km worth of diy oil changes, I’ve yet to change a crush washer, and yet to have a drain plug leak. I always replace them on friends’ Toyotas, because they seem more important, but on every car I’ve owned it hasn’t mattered. And if you take the least amount of effort to google “how to change oil on ________” (fill in the blank for your year, make, model), some forum or video will probably tell you exactly wha…

Costs me 15 cents per washer delivered, why bother risk it? The world doesn't need more cancerous used motor oil on the ground.

After downloading a service manual and doing many things myself it became very apparent that mechanics barely bother to do work the right way despite it coming at virtually zero extra effort.

It's quite rare to see them use a torque wrench on many bolts and if you ask them why "they know it by feel", cool, but why not use a torque wrench to the proper specs anyway? It's not any harder.

Re: Malicious npm packages detected across Red Hat Cloud Services

#452

Post by rob_c »

duozerk wrote: post #175
rob_c wrote: post #114

Earlier quoted context omitted.

So why else do we pay someone to package and certify/verify open source projects? This is absolutely 90++% of what should be RedHats core day job.

Non-profit Open Source distributions also and already package and verify open source packages (arguably often with a higher quality of analysis than Red Hat). You pay red hat for compliance reasons (availability of a support you'll never call, mostly).

> You pay red hat for compliance reasons

You may, have you heard of docker?

Re: Malicious npm packages detected across Red Hat Cloud Services

#453

Post by chrisweekly »

darth_avocado wrote: post #129
chrisweekly wrote: post #83

Earlier quoted context omitted.

"maybe high and critical vulnerabilities don’t need to be a minor version upgrade" huh? what do you suggest instead?

A separate pathway to updates. At the moment there is a pressure to keep all the packages updated at all times. Every time a new version of a random package deep in the dependency tree gets published, you roll a dice: is it a bunch of bug fixes that I don’t care about or a vulnerability patch that need to apply immediately? Since it could be either most devs just auto pilot on updates. This creates an environment whe…

Huh? Sorry but both of your comments are frankly incoherent. I have deep experience maintaining large dependency graphs and empatjize with the frustration about CVEs in deep transitive deps, but I can't make head or tail of your "separate pathway".

Re: Malicious npm packages detected across Red Hat Cloud Services

#454

Post by Uvix »

Pxtl wrote: post #381
Uvix wrote: post #363

Earlier quoted context omitted.

But just the dependency list isn't sufficient to pick a specific version, thanks to dependency ranges. If Package A depends on Package B >= 1.0, and Package B has v1.0 and v1.1 available, it will use v1.0. But if Package B suddenly unlists v1.0, then future restores will change to v1.1.

Ah, I see the worry. A supply-chain attacker can use de-listing to force an upgrade to the malicious version if clients have dependency ranges that reach into the future. I didn't know about that one. In general, any dependency system that allows "you can silently upgrade to versions of the package that did not exist at the time the packagereference list was created" seems to be a vulnerability. It's frustrating sinc…

It seems trivially simple until you have two dependencies with conflicting exact version requirements... So I don't think you can get rid of floating versions entirely. They did add NPM-style lockfiles for PackageReference, but currently not mandatory.

The version numbers for BindingRedirects are orthogonal to the package versions. You can have multiple package versions use the same AssemblyVersion so that applications don't need to create BindingRedirects. (e.g. Newtonsoft.Json - 13.0.0, and 13.0.1 in NuGet are both 13.0.0.0 for binding redirect purposes) And .NET Core/5+ don't need BindingRedirects at all!

Re: Malicious npm packages detected across Red Hat Cloud Services

#455

Post by user3939382 »

zwily wrote: post #336
user3939382 wrote: post #267

Earlier quoted context omitted.

If this were a universal default, would the strategy defeat itself?

Even if everyone used it, the security scanners would still have time to do their static analysis of new packages. Basically, all the clients implementing a delay would create a de facto quarantine status for new packages so they can be examined before everyone starts installing them. (Why npm doesn't just implement that themselves, I do not know.)

Then shouldn’t the analyzers just be part of NPMs acceptance requirements?

Re: Malicious npm packages detected across Red Hat Cloud Services

#456

Post by nicolewhite »

throwawayffffas wrote: post #377
nicolewhite wrote: post #324

Earlier quoted context omitted.

From that repo: > Exact version pinning — specifying precise versions (1.0.0, ==1.0.0, =1.0.0, = 5.31.0) rather than ranges (^, ~>, >=) in package manifests. Ranges allow any version satisfying the constraint to be resolved at install time; exact pins mean only one version is ever valid. My understanding is that pinning the dependency within the manifest isn't the mechanism that prevents the version from changing acr…

Specifying precise versions is sufficient to ensure that the packages in your package.json are installed in the pinned versions. The problem solved by lockfiles is second, third and n-order dependencies. Just because you pinned precise versions does not mean react or vue or whatever random package you installed did as well. That's where the lockfile comes in, it pins the dependencies of the dependencies.

The lockfile also handles the first-order dependencies, though. Pinning them in the manifest doesn't enforce this -- the lockfile does. And yes, I agree that the lockfile _also_ handles pinning dependencies-of-dependencies.

Re: Malicious npm packages detected across Red Hat Cloud Services

#457

Post by naruhodo »

eranation wrote: post #234

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…

> but if you have a loved one who just needs a one click fix, these can likely save them from the next attack.

I'm not letting gam gams anywhere near that shit. She can continue writing her own apps in assembly language - it's good for her brain health!

Re: Malicious npm packages detected across Red Hat Cloud Services

#458

Post by smohare »

jmb99 wrote: post #358
Normal_gaussian wrote: post #319

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…

Changing oil requires > 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, bor…

[dead]

Re: Malicious npm packages detected across Red Hat Cloud Services

#459

Post by zwily »

user3939382 wrote: post #455
zwily wrote: post #336

Earlier quoted context omitted.

Even if everyone used it, the security scanners would still have time to do their static analysis of new packages. Basically, all the clients implementing a delay would create a de facto quarantine status for new packages so they can be examined before everyone starts installing them. (Why npm doesn't just implement that themselves, I do not know.)

Then shouldn’t the analyzers just be part of NPMs acceptance requirements?

That’s my point. For whatever reason, npm isn’t doing it. All npm users adding a minimum package age is kind of like doing it as a collective, without npm’s help.

Re: Malicious npm packages detected across Red Hat Cloud Services

#460

Post by OrangeMusic »

rochak wrote: post #149

If this is what will take for folks to move away from JS ecosystem, I'll take it.

I honestly don't understand how you could do JS on the backend in 2026. This language and ecosystem are so bad it's ridiculous. Almost all other options (yes, even PHP) are better.

On the browser at least you have the excuse that there's no other option (hoping Wasm will eventually kill JS for good, but we're not there yet).

Post reply on HN