[Suggestion] Handling Rust in upcoming releases

[Suggestion] Handling Rust in upcoming releases

[rsbecker]

Hi All,

I would like to propose a mechanism where some platforms can keep using git
even where Rust is not available.

Basically, make Rust a dependency for commands that need Rust but for those
that are still in C, do not require rust. This will mean that git can keep
being
available, but new development can be done in Rust. It also means that
CVE patches, if they come, can be done without leaving non-Rust platforms
hanging out in the cold. It does mean that some commands will not be
available on some platforms. This has been a well-established position
by git for many years for other non-portable dependencies, like p4,
subversion, and send-mail.

Please consider this as a compatibility suggestion. It will give platforms
who have plans to implement Rust (eventually), time to react, as Rust
is a non-trivial port without gcc being available also.

Sincerely,
Randall

--
Brief whoami: NonStop&UNIX developer since approximately
UNIX(421664400)
NonStop(211288444200000000)
-- In real life, I talk too much.

Re: [Suggestion] Handling Rust in upcoming releases

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 3029 bytes --]

On 2025-08-26 at 18:04:26, rsbecker@nexbridge.com wrote:
> Hi All,
> 
> I would like to propose a mechanism where some platforms can keep using git
> even where Rust is not available.
> 
> Basically, make Rust a dependency for commands that need Rust but for those
> that are still in C, do not require rust. This will mean that git can keep
> being
> available, but new development can be done in Rust. It also means that
> CVE patches, if they come, can be done without leaving non-Rust platforms
> hanging out in the cold. It does mean that some commands will not be
> available on some platforms. This has been a well-established position
> by git for many years for other non-portable dependencies, like p4,
> subversion, and send-mail.

Unfortunately, this is going to be very difficult.  The first proposed
Rust change will wire up the diff code to use Rust.  That's used in a
lot of places, including diff, log, format-patch, show, and others.

I plan on using it to implement a new format for the SHA-1/SHA-256
interoperability mapping, which will be involved in a large number of
code paths: index-pack, fetch-pack, upload-pack, and others.
Theoretically it could be compiled out if someone doesn't need that
functionality, but then all of the code that is involved in speaking to
remote systems needs to learn to not activate, and that's a lot of messy
conditional code that almost nobody will test.

A lot of the memory safety and performance benefits that we'll get from
using Rust code are going to involve core functionality.  I will admit
to having written my share of segfaults in my time as a C programmer,
and if I can write substantially fewer of those by using Rust in core
places in the code, I'd like to do that, especially if that means we
have fewer security problems.

It also contradicts the proposed policy.  Under non-goals:

    Implementing C-only versions of Rust code or compiling a C-only Git.
    This would be difficult to maintain and would not offer the
    ergonomic benefits we desire.

It also doesn't address the memory safety benefits outlined in that
document, including the fact that memory safety vulnerabilities
constitute about 70% of vulnerabilities in software written in
memory-unsafe languages or that the U.S. government is planning to
classify development in memory-unsafe languages as a "Product Security
Bad Practice".[0]

So I don't think this approach is going to work.

[0] To be clear, I don't mention this because I agree with everything
that the U.S. government says or does (I certainly don't), but because
this advice (which I believe is correct) is influential on policies
around the world, including in governments and large companies, and that
will affect people's willingness to use and adopt Git.  I would like Git
to continue to be the version control system of choice for users around
the world, whether at home, at work, or in the government.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]