Re:Hard Rust requirements from May onward for all Debian ports
by dcsommer on Saturday November 01, 2025 @12:08PM
(#45782779)
> basically fine
How many type confusion 0 days and memory safety issues have we had in dynamic language engines again? I've really lost count.
Re:Hard Rust requirements from May onward for all Debian ports
by gpm on Saturday November 01, 2025 @12:22PM
(#45782910)
Are you counting ones that involve running malicious code in a sandbox and not just trusted code on untrusted input? Because then I'd agree, but that's a much harder and different problem.
My impression is that for the trusted code untrusted input case it hasn't been that many, but I could be wrong.
Re:Hard Rust requirements from May onward for all Debian ports
by bigyabai on Saturday November 01, 2025 @01:44PM
(#45783632)
It depends, what language was the sandbox written in?
Re:Hard Rust requirements from May onward for all Debian ports
by gpm on Saturday November 01, 2025 @01:47PM
(#45783668)
Sandboxes are difficult independent of language, see all the recent speculation vulnerabilities for instance. Sure, worse languages make it even harder, but I think we're straying from the original topic of "python/ruby" by considering sandboxes at all.
Re:Hard Rust requirements from May onward for all Debian ports
by zahlman on Saturday November 01, 2025 @09:59PM
(#45787255)
How many ways to cause a segmentation fault in CPython, that don't start with deliberate corruption of the bytecode, are you aware of?
How is "type confusion" a security issue?
All (current) languages eventually have a compiler/runtime that is memory unsafe. This is basically fine because it's a tiny amount of surface area (relative to the amount of code that uses it) and it exists in a way that the input to is relatively benign so there's enough eyes/time/... to find bugs.
There's also nothing stopping you from re-implementing python/ruby/... in a safer way once that becomes the low hanging fruit to improve computer reliability.