RE: [PATCH v3 02/15] xdiff: introduce rust

[<rsbecker@nexbridge.com>]

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.