|
| 1 | +Usage of Rust in Git |
| 2 | +==================== |
| 3 | + |
| 4 | +Objective |
| 5 | +--------- |
| 6 | +Introduce Rust into Git incrementally to improve security and maintainability. |
| 7 | + |
| 8 | +Background |
| 9 | +---------- |
| 10 | +Git has historically been written primarily in C, with some portions in shell, |
| 11 | +Perl, or other languages. At the time it was originally written, this was |
| 12 | +important for portability and was a logical choice for software development. |
| 13 | + |
| 14 | +:0: link:https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html |
| 15 | +:1: link:https://www.cisa.gov/resources-tools/resources/product-security-bad-practices |
| 16 | + |
| 17 | +However, as time has progressed, we've seen an increased concern with memory |
| 18 | +safety vulnerabilities and the development of newer languages, such as Rust, |
| 19 | +that substantially limit or eliminate this class of vulnerabilities. |
| 20 | +Development in a variety of projects has found that memory safety |
| 21 | +vulnerabilities constitute about 70% of vulnerabilities of software in |
| 22 | +languages that are not memory safe. For instance, {0}[one survey of Android] |
| 23 | +found that memory safety vulnerabilities decreased from 76% to 24% over six |
| 24 | +years due to an increase in memory safe code. Similarly, the U.S. government |
| 25 | +is {1}[proposing to classify development in memory unsafe languages as a |
| 26 | +Product Security Bad Practice"]. |
| 27 | + |
| 28 | +These risks are even more substantial when we consider the fact that Git is a |
| 29 | +network-facing service. Many organizations run Git servers internally or use a |
| 30 | +cloud-based forge, and the risk of accidental exposure or compromise of user |
| 31 | +data is substantial. It's important to ensure that Git, whether it's used |
| 32 | +locally or remotely, is robustly secure. |
| 33 | + |
| 34 | +In addition, C is a difficult language to write well and concisely. While it |
| 35 | +is of course possible to do anything with C, it lacks built-in support for |
| 36 | +niceties found in modern languages, such as hash tables, generics, typed |
| 37 | +errors, and automatic destruction, and most modern language offer shorter, more |
| 38 | +ergonomic syntax for expressing code. This is valuable functionality that can |
| 39 | +allow Git to be developed more rapidly, more easily, by more developers of a |
| 40 | +variety of levels, and with more confidence in the correctness of the code. |
| 41 | + |
| 42 | +For these reasons, adding Rust to Git is a sensible and prudent move that will |
| 43 | +allow us to improve the quality of the code and potentially attract new developers. |
| 44 | + |
| 45 | +Goals |
| 46 | +----- |
| 47 | +1. Git continues to build, run, and pass tests on a wide variety of operating |
| 48 | + systems and architectures. |
| 49 | +2. Transition from C to Rust is incremental; that is, code can be ported as it |
| 50 | + is convenient and Git does not need to transition all at once. |
| 51 | +3. Git continues to support older operating systems in conformance with the |
| 52 | + platform support policy. |
| 53 | +
|
| 54 | +Non-Goals |
| 55 | +--------- |
| 56 | +1. Support for every possible operating system and architecture. Git already |
| 57 | + has a platform support policy which defines what is supported and we already |
| 58 | + exclude some operating systems for various reasons (e.g., lacking enough POSIX |
| 59 | + tools to pass the test suite). |
| 60 | +2. Implementing C-only versions of Rust code or compiling a C-only Git. This |
| 61 | + would be difficult to maintain and would not offer the ergonomic benefits we |
| 62 | + desire. |
| 63 | +
|
| 64 | +Design |
| 65 | +------ |
| 66 | +Git will adopt Rust incrementally. This transition will start with the |
| 67 | +creation of a static library that can be linked into the existing Git binaries. |
| 68 | +At some point, we may wish to expose a dynamic library and compile the Git |
| 69 | +binaries themselves using Rust. Using an incremental approach allows us to |
| 70 | +determine as we go along how to structure our code in the best way for the |
| 71 | +project and avoids the need to make hard, potentially disruptive, transitions |
| 72 | +caused by porting a binary wholesale from one language to another that might |
| 73 | +introduce bugs. |
| 74 | + |
| 75 | +Crates like libc or rustix define types like c_long, but in ways that are not |
| 76 | +safe across platforms. |
| 77 | +From https://docs.rs/rustix/latest/rustix/ffi/type.c_long.html: |
| 78 | + |
| 79 | + This type will always be i32 or i64. Most notably, many Linux-based |
| 80 | + systems assume an i64, but Windows assumes i32. The C standard technically |
| 81 | + only requires that this type be a signed integer that is at least 32 bits |
| 82 | + and at least the size of an int, although in practice, no system would |
| 83 | + have a long that is neither an i32 nor i64. |
| 84 | + |
| 85 | +Also, note that other locations, such as |
| 86 | +https://docs.rs/libc/latest/libc/type.c_long.html, just hardcode c_long as i64 |
| 87 | +even though C may mean i32 on some platforms. |
| 88 | + |
| 89 | +As such, using the c_long type would give us portability issues, and |
| 90 | +perpetuate some of the bugs git has faced across platforms. Avoid using C's |
| 91 | +types (long, unsigned, char, etc.), and switch to unambiguous types (e.g. i32 |
| 92 | +or i64) before trying to make C and Rust interoperate. |
| 93 | + |
| 94 | +Crates like libc and rustix may have also traditionally aided interoperability |
| 95 | +with older versions of Rust (e.g. when worrying about stat[64] system calls), |
| 96 | +but the Rust standard library in newer versions of Rust handle these concerns |
| 97 | +in a platform agnostic way. There may arise cases where we need to consider |
| 98 | +these crates, but for now we omit them. |
| 99 | + |
| 100 | +Tools like bindgen and cbindgen create C-styled unsafe Rust code rather than |
| 101 | +idiomatic Rust; where possible, we prefer to switch to idiomatic Rust. |
| 102 | +However, we may use bindgen and cbindgen to share existing Git types as an |
| 103 | +interim step. |
| 104 | + |
| 105 | +Rust upstream releases every six weeks and only supports the latest stable |
| 106 | +release. While it is nice that upstream is active, we would like our software |
| 107 | +releases to have a lifespan exceeding six weeks. To allow compiling our code |
| 108 | +on a variety of systems, we will support the version of Rust in Debian stable, |
| 109 | +plus, for a year after a new Debian stable is released, the version in Debian |
| 110 | +oldstable. |
| 111 | + |
| 112 | +This provides an approximately three-year lifespan of support for a Rust |
| 113 | +release and allows us to support a variety of operating systems and |
| 114 | +architectures, including those for which Rust upstream does not build binaries. |
| 115 | +Debian stable is the benchmark distribution used by many Rust projects when |
| 116 | +determining supported Rust versions, and it is an extremely portable and |
| 117 | +popular free software operating system that is available to the public at no |
| 118 | +charge, which makes it a sensible choice for us as well. |
| 119 | + |
| 120 | +We may change this policy if the Rust project issues long-term support releases |
| 121 | +or the Rust community and distributors agree on releases to target as if they |
| 122 | +were long-term support releases. |
| 123 | + |
| 124 | +This version support policy necessitates that we be very careful about the |
| 125 | +dependencies we include, since many Rust projects support only the latest |
| 126 | +stable version. However, we typically have been careful about dependencies in |
| 127 | +the first place, so this should not be a major departure from existing policy, |
| 128 | +although it may be a change for some existing Rust developers. |
| 129 | + |
| 130 | +We will avoid including the `Cargo.lock` file in the repository and instead |
| 131 | +specify minimum dependency versions in the `Cargo.toml` file. We want to allow |
| 132 | +people to use newer versions of dependencies if necessary to support newer |
| 133 | +platforms without needing to force upgrades of dependencies on all users, and |
| 134 | +it provides additional flexibility for distribution maintainers. |
| 135 | + |
| 136 | +We do not plan to support beta or nightly versions of the Rust compiler. These |
| 137 | +versions may change rapidly and especially parts of the toolchain such as |
| 138 | +Clippy, the lint tool, can have false positives or add additional warnings with |
| 139 | +too great of a frequency to be supportable by the project. However, we do plan |
| 140 | +to support alternate compilers, such as the rust_codegen_gcc backend and gccrs |
| 141 | +when they are stable and support our desired release versions. This will |
| 142 | +provide greater support for more operating systems and architectures. |
0 commit comments