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

Incident Report: CVE-2024-YIKES

nesbitt.io

Post reply on HN
Print view View original

131–140 of 187 posts

Re: Incident Report: CVE-2024-YIKES

#131

Post by dasyatidprime »

fvv wrote: post #126
lynndotpy wrote: post #12

For anyone confused, this is (very good imo) fiction about supply-chain incidents. It had me very worried during a brief scan that it was real though, which made me read it more attentively :)

Just because it's not important to pay attention to CVEs, why not waste the readers' time by creating "fictional" CVEs without a disclaimer in the first line? Just because it's not already difficult to scrape through the information and noise on this internet... especially if it appears on the front page of hackernews

The tag list at the top of the page includes “satire”.

Re: Incident Report: CVE-2024-YIKES

#132

Post by raesene9 »

fragmede wrote: post #48
mac3n wrote: post #44

good thing I don't use npm or pip, just the recommended curl ... | bash

It's curl | sudo bash . Amateur.

So old school, now we get install lines like Tell Opencode to "Fetch and follow instructions from https://raw.githubusercontent.com/obra/superpowers/refs/head..."

From a real repo, with 186K stars... https://github.com/obra/superpowers

Re: Incident Report: CVE-2024-YIKES

#134

Post by lmm »

zbentley wrote: post #24
fleventynine wrote: post #8

Earlier quoted context omitted.

Many small crates published by large, trustworthy projects are fine and preferable to one large crate that "does everything".

Why? Honest question. Commons, Guava, Spring, and more seem to take this approach successfully (as in, the drawbacks are outweighed by the benefits in convenience, quality, and security) in Java. Are benefits in binary size really worth that complexity? And before someone says “just have a better standard library”, think about why that is considered a solution here. Languages with a large and capable standard library…

> Honest question. Commons, Guava, Spring, and more seem to take this approach successfully (as in, the drawbacks are outweighed by the benefits in convenience, quality, and security) in Java.

Commons and Spring have spent significant effort to break themselves up in the past, and would probably come as aggregations of much smaller pieces if they could be started today with the benefit of hindsight.

Re: Incident Report: CVE-2024-YIKES

#135

Post by jruohonen »

If this:

"... old laptop, and 'something Kubernetes threw up that looked important' were stolen from his apartment ..."

was related to:

"... enters his nmp credentials on the phishing site ..."

Then I suppose it is really interesting.

Re: Incident Report: CVE-2024-YIKES

#137

Post by eithed »

lynndotpy wrote: post #12

For anyone confused, this is (very good imo) fiction about supply-chain incidents. It had me very worried during a brief scan that it was real though, which made me read it more attentively :)

Contributing factors are entirely serious

edit: actually more and more thing I'm recognizing as being entirely serious (ie benelovent worms :D); satire indistinguishable from reality

Re: Incident Report: CVE-2024-YIKES

#139

Post by dasyatidprime »

yellowapple wrote: post #105
yk wrote: post #91

Earlier quoted context omitted.

Pull left-pad as dependency presumably.

Which then, inexplicably, pulls left-justify as a recursive dependency.

The dependency cycle is actually the functional mechanism of the code, because they subvert the dedup mechanism in the package manager using a random generation trick. Each recursive copy of the dependencies takes up a little bit more space, which ultimately gets converted to the spaces inserted into the original datum; the caller is expected to adjust the cache settings to signal the desired amount. That's also why if you're using left-justify to process strings, Yarn is recommended for best compatibility. /joke

Re: Incident Report: CVE-2024-YIKES

#140

Post by jcgl »

vsgherzi wrote: post #62
jcgl wrote: post #45

Earlier quoted context omitted.

One man's bloat is another man's batteries-included, I guess? My argument would be that if a more featureful standard library could get Rust closer to the superior dependency culture of Go, it'd be worth it. As-is, Rust dependency trees are just wild.

The rust team is already stretched pretty thin. A larger library is going to put more pressure on them. These libraries are already maintained and used. The rust project should just directly, fund, Shepard and guarantee a level of quality for the packages. The foundation has started some of this with the maintainers fund. No need to force it all into the std lib. Go has experienced breaking issues with changes in the…

Point taken about the core team being stretched thin. But I don't see how the "increase stability of some core crates" is enough to change the packaging practices/culture. Maybe I'm wrong, but you really don't get those ecosystem benefits unless the ~entire ecosystem buys into that set of packages. Which really doesn't happen without stdlib.

Also, I think that your example of Go's breaking crypto changes misses the forest for the trees--the stdlib has been incredibly stable through its history, and the vast majority of packages just never have to worry about it. I'm honestly not aware of a language out there with similar adoption, featureset, and robustness. More to the point, I'm not aware of a language out there with a more reliable stdlib that permits the ecosystem to have small dependency graphs.

Post reply on HN