LWN: Comments on "The top open-source security events in 2024"

NVD project funding at US NIST

raven667 — Tue, 12 Nov 2024 14:19:20 +0000

> the NVD suddenly stopped adding new entries; it is still not clear why that happened

A rhetorical question, but how is it possible that a government service relied upon by many commercial vendors just stops working an no one can get an official response as to why, or even an unofficial one? That seems like a lot of risk in the supply chain for security tools that use this data, is no one paying attention to ensure that the agency has funding and a legal mandate to continue this work. In theory we all pay taxes so we should be able to fund shared services like NVD without too much trouble, but failing that some of the companies which rely on it should fund some lobbyists to bribe officials so they prioritize this service, or they to fund a vendor consortium where security companies pool their efforts to fund a central non-profit which provides enrichment data to them all?

open source and code review

LtWorf — Tue, 12 Nov 2024 13:57:18 +0000

And his curiosity could be satisfied with full access to the sources.

open source and code review

pizza — Tue, 12 Nov 2024 12:20:32 +0000

> I think the xz backdoor was an example of what code review *doesn't* easily catch

As the saying goes, it takes two to tango.

The problem with xz was that that the one supposed to be reviewing contributions (ie the only active maintainer) was actively malicious, and there was nobody else willing/able to perform meaningful reviews of that maintainer's contributions.

> Checking in autogenerated files, checking in binaries, having bits that can't be reproduced on non-developer systems, anything that thwarts code review shouldn't fly.

They didn't check in autogenerated files; in this case the dodgy configure script was only in the release tarball, not the public repo. Meanwhile, the binary file was flagged as a defective file used in regression testing, something quite common for test suites, and it is the overwhelming norm for release tarballs to contain generated configure/build scripts versus what is in the repositories. It also takes "non-developers" to determine that things can't be reproduced on "non-developer systems".

Tl;dr: Calls for "maintainer diligence" are meaningless in the face of actively malicious maintainers.

open source and code review

josh — Tue, 12 Nov 2024 06:07:12 +0000

I think the xz backdoor was an example of what code review *doesn't* easily catch, and a demonstration that code which is resistant to code review should be presumptively rejected by default. Checking in autogenerated files, checking in binaries, having bits that can't be reproduced on non-developer systems, anything that thwarts code review shouldn't fly.

It was also an especially painful demonstration of https://xkcd.com/2347/ and what happens when single-point-of-failure projects get handed off to new maintainers, or pressured to get handed off to new maintainers.

open source and code review

barryascott — Mon, 11 Nov 2024 22:19:45 +0000

Code review did not find the xz vuln, it was the curiosity of a developer, Andres Freund, seeing strange test results when working with Postgresql that unearthed the problem.

open source and code review

ballombe — Mon, 11 Nov 2024 20:01:35 +0000

The whole open source methodology is predicated on code review.
The detection of the xz backdoor was an effect of the open source methodology and cannot be dismissed as an artifact, so equating it with the crowstrike event is not entirely fair.
How much one is able to reduce a risk is a measure of success.

Crowdstrike did happen to Linux,

k3ninho — Mon, 11 Nov 2024 19:10:42 +0000

>There is a Linux version of CrowdStrike's software that didn't break; perhaps that is a result of a better architecture (including the use of BPF rather than kernel modules) on the Linux side.

Similar changes to Crowdstrike's Falcon Sensor/Agent in April yielded similar unbootable circumstances for Debian and Rocky Linux ( https://www.theregister.com/2024/07/21/crowdstrike_linux_... / https://news.ycombinator.com/item?id=41005936 ).

K3n.

"Event" v. "Incident"

JoeBuck — Mon, 11 Nov 2024 18:52:32 +0000

Suggest s/events/incidents/ in the title to fix the issue.

"Event" v. "Incident"

shironeko — Mon, 11 Nov 2024 18:22:23 +0000

same, thought it was a list of security conferences, and wondered why this was a subscriber only article.

"Event" v. "Incident"

Heretic_Blacksheep — Mon, 11 Nov 2024 18:14:50 +0000

Minor nitpick: Event tends to suggest conferences and other social ... events. But then the first sentence in the article makes it clear this is not about social gettogethers at all, but instead open source security problems. I'm willing to bet I'm not the only one that's going to look at the headline with puzzlement as there's only a few security related open source conferences every year.

I mean, it's not *wrong*, but the context of "event" equating to "incident" or "problem" won't be the first one some will consider.