Re: [PATCH 2/4] hash.h: scaffolding for _fast hashing variants

[Junio C Hamano <gitster@pobox.com>]

Patrick Steinhardt <ps@pks.im> writes:

> While the property we care about in the context of this patch series
> indeed is that the second hash is faster, I think the more important
> property is that it's insecure. If I were seeing two APIs, one labelled
> fast and one labelled slow, I would of course pick the fast one. So I
> wonder whether we should rename things accordingly so that developers
> aren't intrigued to pick the fast one without thinking, and also to have
> a more useful signal that stands out to reviewers.

I do not think this topic is going in the direction it set out to,
but if we are to resurrect it by 

 (1) first to ensure that we won't overwrite existing on-disk files
     and other things as needed to safely swap the tail sum to a
     cryptographically insecure hash function;

 (2) devise a transition plan to use a hash function that computes a
     value that is different from SHA-1 (or SHA-256 for that
     matter); and

 (3) pick a hash function that computes a lot faster but is insecure
     and transition to it.

we will need to clearly label the two hash functions as such.

We may also need to consider similar points if we need to name
pseudo random numbers we use, to clarify the requirement of the
caller (e.g., can a caller that wants security use it?).

Thanks.