The version control system underpinning virtually every software project on Earth shifted its build requirements this week. Released on June 11, 2026, Git 2.55-rc0 is the first tagged candidate for the forthcoming Git 2.55 stable release — and its headline change is that Rust support is now enabled by default for the first time. Any build environment that compiles Git from source and does not carry a Rust toolchain will fail unless the maintainer explicitly sets the new NO_RUST flag.
That is the immediate action item. The deeper story is why this is happening at all.
Memory Safety Bugs Drove Two Critical Git CVEs
Git has been written in C since Linus Torvalds created it in April 2005. C gives a programmer complete control over memory — and no protection from misusing it. Buffer overflows, use-after-free errors, and out-of-bounds reads are all possible in C code, and preventing them requires sustained developer discipline. That discipline has limits.
In December 2022, the Git project disclosed two critical vulnerabilities — CVE-2022-41903 and CVE-2022-23521 — both rooted in integer overflow and heap-based memory corruption in Git's C codebase. Both enabled potential remote code execution. The January 2023 security audit by firms X41 D-SEC and GitLab, sponsored by the Open Source Technology Improvement Fund, found that beyond those critical flaws, Git's C code contained a large number of integer-related issues that could lead to denial-of-service conditions, out-of-bounds reads, and memory corruption. The auditors concluded that "the sheer size of the codebase makes it challenging to address all potential instances of these issues."
This is not a Git-specific problem. Microsoft has reported that roughly 70% of its CVEs each year are memory safety issues. Google reports a similar figure for the Chromium codebase. In June 2025, the National Security Agency and Cybersecurity and Infrastructure Security Agency jointly published guidance calling on the software industry to shift to memory-safe programming languages, noting that Google Project Zero research found 75% of CVEs exploited in the wild were memory safety vulnerabilities.
Rust is memory-safe by design. Its ownership and borrow-checker system enforces at compile time that a variable can have only one mutable reference at a time, that references cannot outlive the data they point to, and that memory is freed exactly once. These guarantees eliminate buffer overflows, use-after-free errors, and data races — not at runtime, not through a garbage collector, but through a type system that refuses to compile unsafe patterns. That is why Git is adopting it.
How Git 2.55 Integrates Rust Without Breaking C
Git is not being rewritten in Rust. The project is pursuing an incremental approach: Rust code is built separately by Cargo — Rust's package manager and build tool — into a static library. The existing Makefile or Meson build system then links against that library. C-to-Rust interoperability is handled through Rust's Foreign Function Interface, with the cbindgen tool generating C-compatible header files from the Rust crates so the C code can call into the Rust implementation.
In Git 2.55, the focal point of this work is xdiff — the engine that computes differences between file versions. The xdiff subsystem implements Eugene W. Myers' O(ND) difference algorithm (the workhorse behind git diff) along with the patience and histogram variant algorithms used for more readable output. This subsystem sits in the hot path of git diff, git log -p, git show, and merge operations — meaning it executes on virtually every diff, every log inspection, and every merge. Developer Ezekiel Newren's patch series introducing the xdiff Rust port notes that the Rust implementation is expected to accelerate xdiff by between 5 and 19 percent compared to the current C implementation.
Git 2.55 does not yet complete that port — it lays the groundwork by making the xdiff C code compatible with the Rust FFI layer and by establishing the xdiff and ivec Rust crates as the foundation for subsequent patches. The full xdiff Rust migration will follow in later releases.
There is one important boundary to understand. Rust's memory safety guarantees apply only to code written in Rust. The FFI boundary itself is marked unsafe in Rust, meaning the compiler's safety checks do not extend to C code calling into Rust, or to Rust calling into C. During the transition period, Git's codebase contains both languages, and the connections between them require careful handling. The Rust components become progressively safer as more subsystems migrate; the C components carry their existing risk profile until they are replaced.
What Changed in the Build System: Opt-Out While You Can
Up to and including Git 2.54, developers who wanted Rust support had to explicitly request it by setting WITH_RUST=1 in the standard Makefile build, or by using the Meson build system where Rust was an optional feature. That assumption is now reversed.
Starting with Git 2.55: in the Makefile build, the WITH_RUST option has been renamed to NO_RUST. A build with no flag will now require Rust. A build that explicitly sets NO_RUST will suppress it. In the Meson build, the rust option defaults to enabled and can be set to disabled explicitly.
The stable Git 2.55 release is expected within the coming weeks, following the standard release-candidate testing window. Distribution maintainers and CI pipeline operators have that window to audit their environments.
Patrick Steinhardt, the contributor who formalized Rust's integration into Git's build infrastructure, included documentation of the mandatory requirement in the patch series he submitted in September 2025. With Git 3.0 — targeted for late 2026 — the opt-out will be removed entirely. There will be no NO_RUST flag, no disabled Meson option, and no path to building Git without a Rust toolchain.
Git Mirrors a Wider Open-Source Pivot
Git is not the first critical open-source tool to follow this path. The pattern is consistent: long-lived C projects are not being wholesale replaced, but their most security-sensitive components are being rewritten in Rust, subsystem by subsystem.
The Linux kernel first accepted Rust driver code in version 6.1. Ubuntu 26.04 LTS — which shipped in April 2026 and is supported until 2031 — made sudo-rs, a Rust reimplementation of the sudo privilege-escalation utility, its default. That distribution is anticipated to reach tens of millions of users. The curl HTTP library has added a Rust-based backend. uutils, a Rust rewrite of the GNU core utilities, is under active development and is part of Ubuntu's broader roadmap for replacing C implementations of system tools.
Git's migration fits the same model: a trusted, battle-tested C codebase identifying its most vulnerable hot-path subsystem, porting it to Rust for the memory-safety guarantee, and distributing that work across a measured multi-release timeline rather than demanding an overnight rewrite.
What Developers and Packagers Need to Do Now
For developers and distribution maintainers who build Git from source, three action items apply before the Git 2.55 stable release ships.
Verify Rust toolchain availability. Any build system that does not pass NO_RUST (Makefile) or set the Meson rust option to disabled will require a working Rust compiler. Confirm the minimum supported Rust version against the official Git 2.55 release notes once they publish; related infrastructure projects such as sudo-rs have standardized on Rust 1.85 as a baseline, and Git's requirements are expected to be similar.
Audit CI pipelines. Automated build systems that compile Git as a dependency — including container images, build agents, and embedded toolchains — should be tested against the rc0 release now, before the stable release lands.
Update downstream packages. Linux distribution maintainers packaging Git will need to declare a Rust build dependency in their package specs, or explicitly opt out, before the 2.55 packaging cycle closes.
Organizations targeting a longer planning horizon should note that Git 3.0, when it ships in late 2026, will make Rust an unconditional requirement. Any environment that cannot carry a Rust toolchain — constrained embedded systems, air-gapped networks, older distribution build environments — needs a strategy before that release.
Frequently Asked Questions
Does Git 2.55 require Rust to build?
Not strictly, but Rust is now on by default. Any build that does not explicitly pass the NO_RUST flag (in the Makefile build) or set the Meson rust option to disabled will require a Rust toolchain. Developers and distribution packagers who want to suppress Rust must now actively opt out rather than passively ignore it.
How do I disable Rust in a Git 2.55 build?
In a standard Makefile build, pass NO_RUST=1 (the option was previously called WITH_RUST; the rename is intentional). In a Meson build, set the rust option to disabled. Both paths remain available until Git 3.0, at which point the opt-out is removed and Rust becomes an unconditional build requirement.
When will Git 3.0 be released, and will it require Rust?
Git 3.0 is targeted for late 2026, though no firm date has been set. The Git project has formally announced that Rust will be a mandatory build dependency for Git 3.0 with no option to disable it. This gives distribution maintainers and build system operators approximately six months to ensure Rust toolchains are available in all environments that compile Git from source.
Why is Git adding Rust at all?
A 2023 security audit of Git's C codebase by X41 D-SEC and GitLab found two critical remote-code-execution vulnerabilities rooted in heap memory corruption — the exact class of bug Rust's type system prevents at compile time. The NSA and CISA have documented that approximately 70% of all exploitable software vulnerabilities in C codebases are memory-safety issues. Git's Rust migration is a response to that systemic risk: Rust's borrow checker eliminates buffer overflows, use-after-free errors, and data races without the performance cost of a garbage-collected language.
ⓒ 2026 TECHTIMES.com All rights reserved. Do not reproduce without permission.
