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 3 days ago | parent | next [-]

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 3 days ago | parent | next [-]

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 3 days ago | parent | prev [-]

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

	▲	johnisgood 2 days ago \| parent [-]
		Which are more likely to be introduced by a full rewrite.

▲

aw1621107 3 days ago | parent | prev [-]

> 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 a day ago \| parent [-]
		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.