Re: [PATCH] Remove non-SHA1dc sha1 implementations

From: Jeff King <peff@peff.net>
Date: Feb 24, 2020, 04:47 UTC
Message-ID: <20200224044732.GK1018190@coredump.intra.peff.net>
In-Reply-To: <20200223223758.120941-1-mh@glandium.org>

On Mon, Feb 24, 2020 at 07:37:58AM +0900, Mike Hommey wrote:

> It is 2020, and with the weakening of SHA1 security-wise, there doesn't
> seem to be a reason to support anything else than SHA1dc, with collision
> detection.

One possible reason is that they're way faster than sha1dc (block-sha1 maybe only a little, but openssl's sha1 is over twice as fast).

To be clear, I think the slowdown is worth the extra safety, but:

 - do we still want to care about people who prefer to make the tradeoff
   differently?

 - when we first switched the default to sha1dc, the idea was raised of
   continuing to use a faster implementation for non-security checksums
   (e.g., the checksums at the end of packfiles, index files, etc). I
   don't think anybody ever implemented that, but it's not a terrible
   idea. OTOH, if nobody noticed the bottleneck enough to care, maybe
   it's not worth worrying about.

I'm not convinced the answer to those questions is "yes", but I think it's worth at least raising them (and arguing against them in the commit message).

One thing that compels me is the recent report that we still build with common crypto by default on macOS, which was definitely _not_ intended. That's a bug that can be fixed, but it wouldn't have happened in the first place if we only supported sha1dc.

-Peff