On Sat, Aug 23, 2025 at 11:30:26AM -0700, Elijah Newren wrote: > > The assertion in the policy that Rust is easily interoperable is incorrect. > > Are you mixing up interoperability with portability? Without further > context than your email provides, it appears so to me. Rust code can > call C code and vice-versa within the same process without huge > amounts of serializing and deserializing of data structures, and > without what amounts to something close to an operating system context > switch in order to ensure call stacks are as expected for the language > in question. To me, that means we can call the two languages easily > interoperable. On the other hand, portability of those languages is > about whether those languages have compilers supported on various > hardware platforms. The document explicitly calls out that fewer > systems have a Rust compiler than have a C compiler, and that Rust > adoption would thus reduce how portable Git is. Are you referring to > this lower portability that the document itself also calls out, or are > you pointing out additional issues with interoperation between the > languages on a platform where compilers for both languages exist? If > the latter, could you provide more details? I think that this is the main point from my point of view. Yes, we are strictly worsening the project's portability by adding Rust as a non-optional build component. But it is *not* the case that two Git clients (one hypothetical one built with Rust components, one existing one without) can't work on the same Git repository, even including one on the same machine. Forgetting Rust for a moment, I don't think it is a realistic goal to have support for all platforms that could possibly want to run Git. I would imagine that there are platforms today that cannot run the latest and greatest version of Git for just that reason. My hope is that whatever version(s) *are* compatible with those platforms are good enough to support the workflows that those users need. So my personal feeling is that that (not having a 100% portable version of Git across all possible platforms) is OK. But of course that does raise the concern that security fixes will be more difficult to backport across a hypothetical version boundary where Rust is introduced. To that end, I would note a couple of things: - This assumes that the Rust code has the same security vulnerabilities as the C code that it replaces. I don't think that is a given whatsoever, and I would bet that emperically there are fewer such vulnerabilities on the Rust side than on the C one (in fact, that is one of the reasons that we are considering Rust in the first place; brian m. carlson explains this point quite well IMHO). - If there *is* a security vulnerability in the Rust code that also presents a vulnerability on the corresponding C side, I would hope that the project's track record of generously backporting security fixes would suggest that we would do so in this case as well, despite crossing a language boundary. On the other side of that coin, if there is a security vulnerability in an older version of Git that isn't present in a newer one (regardless of whether or not Rust is involved), I would imagine that that we would write security patches against an even earlier maint- branch and forward-port them up to the most recent vulnerable version. So my impression is that the main contention here is a concern that worsening the portability will make it harder to push out security fixes in either direction. But I don't think that's necessarily the case. Even if it is, I would again hope that the track record of the folks on the git-security list would suggest that we'd do the right thing and not abandon users on older platforms the moment Rust is introduced into the codebase. Thanks, Taylor
