From: rsbecker@nexbridge.com Date: Mon, 08 Sep 2025 15:36:50 GMT Subject: RE: [PATCH v3 02/15] xdiff: introduce rust Message-ID: <049401dc20d6$69086400$3b192c00$@nexbridge.com> In-Reply-To: On September 8, 2025 11:31 AM, Elijah Newren wrote: >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. Linux has one set of rules, and other platforms have others. I do not define the audit requirements for PCI, SWIFT, or HIPPA compliance (and other rules outside of North America), which apply one way or another to most of my community. The audit teams, which are both internal to the companies and at governmental regulatory levels, do this. It is 100% out of my control but is a reality. Fixes to any code involved in managing financial and health instruments must be done by authorized and recognized sources. I am not one of them.