On August 26, 2025 9:58 PM, Taylor Blau wrote: >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. This is indeed my concern and hope, Taylor, as the maintainer for a platform that is feeling abandoned. Please note that HPE NonStop is an actively maintained and vendor supported commercial platform based on x86_64 POSIX, just not a Linux/Windows machine. Thank you.
