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

From: rsbecker@nexbridge.com <rsbecker@nexbridge.com>
Date: Sep 8, 2025, 15:32 UTC
Message-ID: <049301dc20d5$d1643340$742c99c0$@nexbridge.com>
In-Reply-To: <ad54bb8f-04e4-4bf7-a13f-6ae7b967b718@gmail.com>

On September 8, 2025 6:12 AM, Phillip Wood wrote:

Show 38 quoted lines

>On 07/09/2025 17:09, rsbecker@nexbridge.com wrote:
>> On September 7, 2025 12:10 AM, Elijah Newren wrote:
>>> Sorry for the delay; life outside of work is challenging at the moment...
>>>
>>
>> I am going to address the critical point mentioned below and snip the rest for
>brevity.
>>
>>> I still don't see why distributors _must_ ship the latest version of
>>> Git and why folks on some platforms are considered broken if they are using a
>slightly older version.
>>> Let me ask again: has anyone answered why this is considered
>>> mandatory?  If they have, I've missed it, but I've asked multiple
>>> times.  Even if you want to lump "distributors cannot build a newer
>>> version" under the umbrella of "breaking changes", I argue it's a
>>> much different kind of break and one which merits different timelines for
>handling than e.g. lumping it in with 3.0.
>>
>> I do not see that distributors _must_ ship the latest version. Suppose
>> we are on
>> 2.51.0 and a CVE comes out that prohibits its use in an organization
>> that does not allow any medium-high to high CVEs. This represents
>> hundreds of thousands of impacted users in my community alone. How
>> does the CVE get applied if the latest cannot be built and the git
>> team does not apply the CVE fixes to old versions. Personally, I do
>> not care if git versions are different between work and home, or even
>> between CI/CD and other platforms. I don't even care if I have to use
>> JGit instead of git in some situations (which I see is a likely
>> outcome of this discussion). Is there an official statement of what an LTS means?
>
>We're currently discussing what promises we can make about supporting a non-rust
>version of git.
>
>> In other projects LTS is typically, and formally by policy 5 years.
>
>I know commercial linux distributions offer that kind of support but are there really
>open source projects that guarantee 5 years of security updates without any kind
>of support contract?

OpenSSL provides 5 years of security fix support (at no cost) for LTS designated releases. Currently 3.0 ending Sept 2026 and 3.5 ending around October 2030. After those dates, there is a fee-based support arrangement available.

Show 17 quoted lines

>>  From what others have said here, positions of 6 months, 3 years, and
>> "apply it yourself if you want to continue to use git" have been made.
>
>Yes it is still being discussed, and no one is volunteering to offer five years of
>support.
>
>> The core problem of adding a breaking dependency is when a CVE comes
>> out that prohibits git from being used at all. If the git team is not
>> going to provide a clear statement, one way or another, if how CVEs
>> (at whatever severity level) will not have a commitment of any kind,
>> then distributors are essentially cast adrift and on our own. It would
>> be helpful of those of us who donate our time, for no compensation,
>> are able to plan for this in a meaningful way.
>
>Doesn't your company make a front end to git? Are you saying that the
>management does not allocate any staff time to work on git itself and expects the
>community to provide it with free security updates?

The REAL PROBLEM that is not being addressed in this thread is that large companies (the ones who process your credit cards, build your cars, manufacture your drugs, and tool your factories (a.k.a. NonStop customers), are generally unwilling to accept CVE fixes from third parties. The fixes have to be part of the official code base or the fixes will not accepted. That means that either:

1. the git team has to officially sanction the fixes; or

2. do the fixes themselves.

A compromise may be possible to keep a support branch around in the official git repo, for those of us who do not have rust available to contribute to, specifically for post C-deprecation CVE fixes, but I am not sure this is practical. It would also require occasional assistance from the git team, to make sense of some of the fixes, If they apply, as none of us are rust experts.

I am already allocated to spending between 10 and 20 hours a month to git, which usually involves running and verifying build/test cycles. Since git tests are flakey, in some cases, I have to manually examine each failure situation and decide whether the failures are sufficient to pass the releases. These have been reported previously without resolution and do not bear discussion here.

It is important to understand that many git customers in high audit situations build git on their own because they do not trust third party builds, so this needs to remain an option.

Show 5 quoted lines

>> Please remember that
>> we have to justify our participation to our management teams to be
>> allowed to continue to participate.
>I'm confused by this, as the sentence before say's you're donating your time for no
>compensation.

My company pretends to donates my time with very little direct benefit to them. My participation is because I feel it is important for my community. No, I do not get a salary for my git time. It is evenings and weekends. Any time I spend during working hours has to be made up during off hours.

Show 17 quoted lines

>
>> Nothing is free from this end
>> and if fixing (not just applying fixes) CVEs are now 100% our
>> responsibility, if would be critical to know that when we build our
>> business cases to our bosses, who I am fairly certain will say an
>> emphatic no.
>
>In the long term, unless your platform gains a rust compiler I'm afraid I think that is
>most likely outcome.
>
>> Also remember that without support from the git team, the code base is
>> no longer the same, meaning the auditors will not necessarily accept
>> fixes from third-party sources.
>
>I think I saw a suggestion/question about the possibility of hosting any long term
>support branch that is maintained by interested parties within the main repository.
>Would that help?

DEFINITELY. With assistance as above. With some help, we may be able to make this work. It might require a deeper participation on my part and those on my team to approve changes, which we would consider.

>I appreciate that any move to rust would be very disappointing and disruptive to
>you but the community has to weigh up the benefits rust has to offer against that.

The community has plans for Rust but they have not taken shape fully as of yet. I have personally been badgering product management to make this happen, and I might know more in a month or so. However, this takes time, and 6 months is not enough.

--Randall