Rustaceans at the border [LWN.net]

Rustaceans at the border

Posted Apr 19, 2022 14:30 UTC (Tue) by rahulsundaram (subscriber, #21946)
In reply to: Rustaceans at the border by farnz
Parent article: Rustaceans at the border

> Your link is truncated - I'm guessing you mean this OpenSSL predictable RNG security advisory?

Correct. Thanks

to post comments

Rustaceans at the border

Posted Apr 19, 2022 16:58 UTC (Tue) by amacater (subscriber, #790) [Link] (4 responses)

This is a favourite stick to drag up to beat Debian with: what's more interesting is to actually go back and realise what happened when it came to light. The work by Luciano Bello was first class: Debian's response was clear and relatively immediate - explain the problems with OpenSSL and thereby OpenSSH fully, create a tool to deny-list problem keys, explain what needed regenerating and why.

The mistake came as a result of actually querying with the upstream maintainers what should be done and doing it inappropriately once too often. I haven't seen other incidents handled as well by other teams and other distributions - let alone by commercial software. It's worth looking at as something being handled well at the time and in retrospect, not necessarily trotted out at every opportunity 14 years later

Rustaceans at the border

Posted Apr 19, 2022 17:36 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (3 responses)

> This is a favourite stick to drag up to beat Debian with

As I specifically noted already, it was just an example of a distribution specific vulnerability that is more well known (and it has some significance due to OP's reference to apt but mostly incidental). Your defensive reaction to that specific example does nothing to address the broader point. Replace that example with another distribution example if it helps you, here you go:

https://nvd.nist.gov/vuln/detail/CVE-2007-5962

We can certainly find more across distributions since everytime backporting or distribution specific patching happens (even as simple as a permissions change in the filesystem), there is deviations from upstream that introduces some potential risk of bugs including security vulnerabilities that don't exist upstream. So the broader point is that humans are infallible and occasions make mistakes (not even counting malicious attackers) and we shouldn't automatically rely on distributions to provide us a better security compared to well vetted upstream projects. Atleast in some cases, they do worse.

Rustaceans at the border

Posted Apr 19, 2022 17:39 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

Correction: humans are not infallible.

Rustaceans at the border

Posted Apr 19, 2022 18:11 UTC (Tue) by amacater (subscriber, #790) [Link] (1 responses)

Well vetted upstream projects is the difficulty. "With enough eyeballs, all bugs are shallow" - not necessarily if the eyelids (or codebases) happen to be effectively closed ... and see the discussions round the security of Chrome/Chromium regularly, for example.

The case of Rust in the kernel is similar to the problems of vendored code necessary to keep some ecosystems running: Node is the obvious one that causes problems to Debian and others.

It's possible that there's just an instinctive awareness of potential problems to come.
There's _so_ much code there that's intertwined and impenetrable and we've all been subject on occasion to being force-marched forwards by large scale change in someone else's ecosystem that we can't control - see, for example init system flamewars or Python 2 -> Python 3 (or a.out to ELF if your memory is long enough).

Rustaceans at the border

Posted Apr 19, 2022 18:28 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

> Well vetted upstream projects is the difficulty

To be clear, the original context here was visiting crates.io website compared to installing a distro package.

> The case of Rust in the kernel is similar to the problems of vendored code necessary to keep some ecosystems running

Vendored code already exists in the Linux kernel. The Rust mechanisms for tracking vendoring is strictly better than the ones we have for vendored C based projects in the kernel.