Re: pushing for a new hash, was Re: [PATCH 2/3] rebase: Add tests for console output

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jonathan Nieder <jrnieder@xxxxxxxxx> writes:

>> 3) the only person who could make that call is Junio
>
> I strongly disagree with this.

If it helps, I _can_ make any set of declarations to make it sound
more official, e.g. (the remainder of) June is the "make sure our
tests are ready" month where we try to eradiate uchar[20] by
advancing the object-id effort, replace EMPTY_TREE_SHA1_HEX and
friends with EMPTY_TREE_OID_HEX, add a build-time configuration that
allows us to build a Git binary that uses a phony hash e.g. ~sha1
truncated to 16 bytes, and build Git with such a configuration and
then run tests, and we concentrate on this effort without adding new
things until we make the tests pass.

And make similar declarations for the remainder of the year.

But the actual input for formulating what each step does and the
timeline we aim for needs to come from the list wisdom; it won't
have much impact if the project's official declaration is not
followed-thru, and a unilateral declaration that is pulled out of
thin-air likely will not be.

> I am happy to solicit more input from security researchers, though,
> and your suggestion to do so is good advice.

One good thing is that we can prepare the framework to adopt a new
hash before knowing what the exact hash function is; crypto-minded
folks can work on the hash selection in parallel without waiting for
the framework to become ready.  And I do agree with Dscho that
having crypto experts would be very helpful for the latter.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]