From: Elijah Newren Date: Mon, 08 Sep 2025 15:31:26 GMT Subject: Re: [PATCH v3 02/15] xdiff: introduce rust Message-ID: In-Reply-To: <042f01dc2011$da9dcda0$8fd968e0$@nexbridge.com> On Sun, Sep 7, 2025 at 9:10 AM 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? In other projects LTS is typically, and formally by policy 5 years. > 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. > > 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. Please remember that > we have to justify our participation to our management teams to be > allowed to continue to participate. 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. > > 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. This particular > point enabled adoption on some platforms, particularly NonStop. > Adoption was at 1-2 customers when we had a divergent code > based because some platform fixes being different from the > standard code-base and could not be certified as valid. Once the > code-base because common, adoption was rapid and enthusiastic. > If this goes away, I suspect that adoption rates will go negative. > I am aware that that particular discussion is actually happening > in some organizations in my community right now, with companies > looking for alternatives to git based on this discussion thread. > > With over a decade of respect and participation, > Randall Thanks, Randall, this is useful information. In regards to one point not fully covered by Phillip: > 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. Why does it need to be "third-party" sources? Linus years ago blessed having someone else be in charge of providing updates for stable releases of Linux. Junio could do the same with Git and similarly mark an individual or group of people as the maintainers for the last Rust-optional version of Git, and those individuals could make official releases of Git with extended security fix support. Then it's not every platform repeating the backporting work that needs to be done, but rather individuals from the affected platform(s) collaborating on that work and then making official first-party releases.