* Re: [Suggestion] Handling Rust in upcoming releases
2025-08-26 18:04 [Suggestion] Handling Rust in upcoming releases rsbecker
@ 2025-08-27 0:51 ` brian m. carlson
0 siblings, 0 replies; 2+ messages in thread
From: brian m. carlson @ 2025-08-27 0:51 UTC (permalink / raw)
To: rsbecker; +Cc: git
[-- 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 --]
^ permalink raw reply [flat|nested] 2+ messages in thread