On Tue, Mar 12, 2019 at 01:09:42PM +0100, Ævar Arnfjörð Bjarmason wrote: > > To be clear, I do sympathize with the notion that not pulling things > > in-tree keeps our relationship with upstream more disciplined, and that > > has value. I'm just not altogether clear how much it's really hurt us > > overall to be undisciplined. > > I agree that say the compat/regex divergence hasn't hurt us much if at > all. Just that we have a few conflicting desires: > > A. Make sure you can "make" git by default without pulling down a bunch > of libraries, especially if they're not ubiquitous. Thus shipping > the likes of sha1dc. > > B. Being able to hotfix those libraries. > > C. Upstreaming those hotfixes when they happen. > > D. Updating the library we pulled in due to "A" from upstream. > > In practice because we've wanted "A" we've felt the need to do "B", but > then also not "C" without ever having the discussion that skipping that > part was a good idea, and as a result "D" is hard. > > Do we urgently need "D"? No. I'm just pointing out that in addition to > optimzing for "B" being easy we should also weigh being good free > software citizens and coordinate fixes with upstream, which also makes a > future "D" easier. Yeah, I think your mental model there makes some sense. > Also, while I don't know of any bugs in compat/regex. I think it's a bit > concerning that we're carrying 2010-era code for something like the > regex engine that we expose e.g. over gitweb. TBH, I think it's probably a bad idea to open any version of that code to untrusted people, because it's easy to write a DoS regex against it. There are libraries (like re2) that would be a better fit (I seem to recall that there may be some DFA-only support in pcre, too, but I haven't looked at it in a long time; if there is, it might be a sane gitweb feature to only expose that engine). -Peff
