Live data from Hacker News

Incident Report: CVE-2024-YIKES

nesbitt.io

21–30 of 187 posts

Re: Incident Report: CVE-2024-YIKES

#22
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?

Maybe give crates a gold star if they have no external dependencies?

Re: Incident Report: CVE-2024-YIKES

#23

It's easy to be cynical because, yes, both the problems and solutions seem dead obvious in hindsight. But for a long time (and maybe even still), a hacker creed was "move fast and break things." It's great that there's so much momentum in fixing the glaring problems with supply chain systems like npm, but I'm concerned that we're entering a new era of security-related problems caused in large part by agentic developm…

> But for a long time (and maybe even still), a hacker creed was "move fast and break things."

Was it? I thought Zuckerberg coined this horrible phrase.

Re: Incident Report: CVE-2024-YIKES

#24
post #3

Earlier quoted context omitted.

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

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 remain more secure than the supply-chain fiascos on NPM because they have a) very large communities reviewing and participating in changes and b) have extremely regulated and careful release processes. Those things aren’t likely to be possible in most small community libraries.

Re: Incident Report: CVE-2024-YIKES

#27

It's easy to be cynical because, yes, both the problems and solutions seem dead obvious in hindsight. But for a long time (and maybe even still), a hacker creed was "move fast and break things." It's great that there's so much momentum in fixing the glaring problems with supply chain systems like npm, but I'm concerned that we're entering a new era of security-related problems caused in large part by agentic developm…

> But for a long time (and maybe even still), a hacker creed was "move fast and break things." Was it? I thought Zuckerberg coined this horrible phrase.

He certainly popularized it (maybe coined it), but I've seen a lot of organizations and developers repeat that mantra.

Even without the specific words, look to product teams debating tradeoffs of going to market vs. waiting for better security controls. They're pushing for faster product release every time, at pretty much every org.

Re: Incident Report: CVE-2024-YIKES

#30
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.

honestly I thought this was the end goal of blessed.rs
Post reply on HN