Live data from Hacker News

Incident Report: CVE-2024-YIKES

nesbitt.io

61–70 of 187 posts

Re: Incident Report: CVE-2024-YIKES

#61
post #3
post #2

Supply chain incidents suck and we need to do better. Personally for rust I’m a proponent of the foundation supporting a few core crates that go under the same audit procedure as the main rust language and give funding to the project to limit supply chain vulns. I don’t think the right answer is to remove systems like crates or npm. Crate and npm are a boon for many developers.

Crates has also been making efforts to include rust sec, but in addition to the above I would like the community to shy away from many small dependencies to a few larger ones just as tokio has

Contrary to what the article here presents, Rust does not have a culture of microlibraries like NPM does. The author and their LLM are cargo-culting a criticism of Rust made by people whose only experience is with the Node ecosystem. The Rust stdlib may not be especially "wide" compared to languages like Python, but it is quite deep, with the objective of making it so that you don't feel the need to publish single-purpose libraries which only exist to fix papercuts. Dozens of new APIs get added with every Rust release, which, occurring every six weeks, amounts to hundreds per year.

Re: Incident Report: CVE-2024-YIKES

#62
post #45

Earlier quoted context omitted.

This bloats the std library and forces lots more work and stress on the rust dev team. Not to mention it’ll add more churn to the std lib.

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 crypto library causing churn in the ecosystem.

Re: Incident Report: CVE-2024-YIKES

#63
post #34
post #9

Earlier quoted context omitted.

Please no, that’s a terrible outcome.

What else would you suggest that also does not have terrible outcomes. The situation as is, is untenable.

As I said above

“Personally for rust I’m a proponent of the foundation supporting a few core crates that go under the same audit procedure as the main rust language and give funding to the project to limit supply chain vulns. I don’t think the right answer is to remove systems like crates or npm. Crate and npm are a boon for many developers.”

This is my solution. We get the quality of a std lib without forcing it in the std Lib and without extra maintaining cost for the team

Re: Incident Report: CVE-2024-YIKES

#64
post #58

According to Pangram, this is likely AI generated, surprised that no one has pointed this out

Not a chance. Far too funny, too well written, too terse while being densely packed with wit. I see zero signs of it being LLM-generated and lots of stuff LLMs have no way of doing.

If I am somehow wrong I would salivate at a chance to see the input.

Re: Incident Report: CVE-2024-YIKES

#65
post #2

Supply chain incidents suck and we need to do better. Personally for rust I’m a proponent of the foundation supporting a few core crates that go under the same audit procedure as the main rust language and give funding to the project to limit supply chain vulns. I don’t think the right answer is to remove systems like crates or npm. Crate and npm are a boon for many developers.

Move high value crates into the standard library?

Indeed, I'm all for maximizing the amount of modules in the standard library. It's pretty obvious to me that Python thrives because of, not despite of, its standard library, "dead batteries" and all.

However, don't make the mistake of thinking that Rust has a small standard library. Read any Rust release and you'll see dozens of new APIs added with every single one. I'm tempted to paste the entire list of stabilized APIs from the most recent release for emphasis, but rather than making this comment three dozen lines longer, just look for yourself: https://blog.rust-lang.org/2026/04/16/Rust-1.95.0/#stabilize...

In particular, most recently the aforementioned release stabilized the cfg_select! macro for convenient conditional compilation, which obviates the popular cfg_if crate: https://doc.rust-lang.org/stable/std/macro.cfg_select.html

Re: Incident Report: CVE-2024-YIKES

#66
Maintainer uses AI to find Yubikey's site.

Hacker uses AI to research countries without extradition to US.

Cops use AI to analyze ransom note. Unfortunately, because the note confidently states that Vietnam has no extradition to the US, the AI recommends paying ransom.

Vietnam's currency, the Dong, confused the AI..

Re: Incident Report: CVE-2024-YIKES

#67
post #58

According to Pangram, this is likely AI generated, surprised that no one has pointed this out

Not a chance. Far too funny, too well written, too terse while being densely packed with wit. I see zero signs of it being LLM-generated and lots of stuff LLMs have no way of doing. If I am somehow wrong I would salivate at a chance to see the input.

The author suddenly began writing a post per day around November 2025. They’re all tongue-in-cheek. I believe you are wrong.

Re: Incident Report: CVE-2024-YIKES

#68

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…

You will have lots of dead code in your build.

That dead code might have "dead dependencies" - transitive dependencies of its own, that it pulls in even though they are not actually used in the parts of the crate you care about.

In the worst case, you can also have "undead code" - event handlers, hooks, background workers etc that the framework automatically registers and runs and that will do something at runtime, with all the credentials and data access of your application, but that have nothing to do with what you wanted to do. (Looking at you, Spring...)

All those things greatly increase the attack surface, I think even more than pulling in single-purpose library.

Re: Incident Report: CVE-2024-YIKES

#69
post #67

Earlier quoted context omitted.

Not a chance. Far too funny, too well written, too terse while being densely packed with wit. I see zero signs of it being LLM-generated and lots of stuff LLMs have no way of doing. If I am somehow wrong I would salivate at a chance to see the input.

The author suddenly began writing a post per day around November 2025. They’re all tongue-in-cheek. I believe you are wrong.

Huh, neat. I will take a look at those.

And actually I see it clearly now, it has a bunch of signs I have called out multiple times myself. (It is entirely made out of lists of various types, and never states an opinion.)

Just my ego getting hold of me because I didn't realize it on my own.

Re: Incident Report: CVE-2024-YIKES

#70
post #42

imagine a future where white-hat vs black-hat "AI" go around the web trying to patch vs exploit 0-days and then become aware of each other and then try to eliminate each other for decades each escalating resource capture and writing new generations of better "AI"

There is definitely an anime about this.
Post reply on HN