[jcrben]

As a user, you may not be aware that C makes it relatively easy to create https://en.m.wikipedia.org/wiki/Buffer_overflow which are a major source of security vulnerabilities.

This is one of the best reasons to rewrite software in Rust or any other more safe by default language.

[msm_]

Everyone on hackernews is well aware that C makes it relatively easy to create buffer overflows, and what buffer overflows are. You're still not responding to GP question.

[jcrben]

I'm not involved in the initiative so I can't answer the question definitively? I provided one of the major reasons that projects get switched from C. I think it's likely to be a major part of the motivation.

[happytoexplain]

I didn't know that C makes it easy.

[sebtron]

Right, I never mentioned that I am a decently experienced C developer, so of course I got my fair share of buffer overflows and race conditions :)

I have also learned some Rust recently, I find a nice language and quite pleasant to work with. I understand its benefits.

But still, Git is already a mature tool (one may say "finished"). Lots of bugs have been found and fixed. And if more are found, sure it will be easier to fix them in the C code, rather than rewriting in Rust? Unless the end goal is to rewrite the whole thing in Rust piece by piece, solving hidden memory bugs along the way.

[rrdharan]

https://access.redhat.com/articles/2201201 and https://github.com/git/git/security/advisories/GHSA-4v56-3xv... are interesting examples to consider (though I'm curious whether Rust's integer overflow behavior in release builds would have definitely fared better?).

> Unless the end goal is to rewrite the whole thing in Rust piece by piece, solving hidden memory bugs along the way.

I would assume that's the case.

[aw1621107]

> though I'm curious whether Rust's integer overflow behavior in release builds would have definitely fared better?

Based on the descriptions it's not the integer overflows that are issues themselves, it's that the overflows can lead to later buffer overflows. Rust's default release behavior is indeed to wrap on overflow, but buffer overflow checks will remain by default, so barring the use of unsafe I don't think there would have been corresponding vulnerabilities in Rust.

[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.