3 ms·
Not really. 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
by gpm 1y ago
Not really.
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.
- dcsommer 1y ago> 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.
- gpm 1y agoAre 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.
- bigyabai 1y agoIt depends, what language was the sandbox written in?
- gpm 1y agoSandboxes 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.
- zahlman 1y agoHow 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?