Re: disabling sha1dc unaligned access, was Re: One failed self test on Fedora 29

[Jeff King <peff@peff.net>]

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