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

[Taylor Blau <me@ttaylorr.com>]

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