[1718627440]

This doesn't matter at all for programs like Git. Any non-free standing program running on a modern OS on modern hardware trying to access memory its not supposed to will be killed by the OS. This seams to be the more reasonable security-boundary then relying on the language implementation to just not issue code, that does illegal things.

Yeah sure, memory-safety is nice for debuggibility and being more confident in the programs correctness, but it is not more than that. It is neither security nor proven correctness.

[TuxSH]

Not quite the best example, since Git usually has unrestricted file access and network access through HTTP/SSH, any kind of RCE would be disastrous if used for data exfiltration, for instance.

If you want a better example, take distributed database software: behind DMZ, and the interesting code paths require auth.

[1718627440]

Git already runs "foreign" code e.g. in filters. The ability to write code that reacts unexpectedly on crafted user input isn't restricted to languages providing unchecked array/pointer access.

[nicoburns]

Unintentional bugs that caused data destruction would also be disastrous for a tool like git

[johnisgood]

Which are more likely to be introduced by a full rewrite.

[aw1621107]

> Any non-free standing program running on a modern OS on modern hardware trying to access memory its not supposed to will be killed by the OS.

This seems like a rather strong statement to me. Do you mind elaborating further?

[1718627440]

I think bugs in the MMU hardware or the kernel accidentally configuring the MMU to allow access across processes that isn't supposed to be are quite rare.

[aw1621107]

Sure, but I think illegal interprocess memory accesses is a fairly narrow definition for "access[ing] memory its not supposed to". There's plenty of undesirable memory accesses that are possible without needing to cross process boundaries and I don't think the OS does that much to solve those outside of currently niche hardware.

[1718627440]

It might be undesirable to you, but you haven't specified this to the computer. Process-boundaries are one way how we specify what is allowed to touch and what not.

[aw1621107]

OK, sure, but there's no reason you can't extend that argument to in-process improper memory accesses either. free() is you specifying that a particular bit of memory isn't supposed to be touched any more, malloc() is you specifying that some amount of memory is legal to access, etc. Language runtimes, inserted/compile-time checks, etc. would be analogous to the OS/MMU here.

[1718627440]

Yes, but this is not across a trust boundary. Since these are in the same process/program. Rust "only" applies checks at compile time, it doesn't enforce security.

Not sure, if I'm clear. Rust is like cooperative multitasking, nice but not guaranteed. My claim here is, that we actually want preemptive multitasking.