[CentOS] Checksums for git repo content?

Thu Feb 23 21:57:59 UTC 2017
Alice Wonder <alice at domblogger.net>

On 02/23/2017 01:03 PM, Lamar Owen wrote:
> On 02/23/2017 03:32 PM, James Hogarth wrote:
>> On 23 February 2017 at 19:55, Lamar Owen <lowen at pari.edu> wrote:
>>> Not to stir up a hornets' nest, but how does Google's announcement at
>>> https://shattered.it affect this now?  (Executive summary: Google has
>>> successfully produced two different PDF files that hash to the same
>>> SHA-1.)
>>> There is a whole paragraph on 'How is GIT affected?'
>> To stave off another ridiculous thread - short version is simply "it
>> isn't"
>>
> Ridiculous?  Seriously?  I don't think it's time to be in panic mode,
> but it is time to prepare for the generation-after-next of GPUs which
> will be able to produce SHA-1 collisions quickly enough to be able to
> keep up with a git repo.
>
> Dan Goodin disagrees that it's not a problem for git in the long run.
> See:
> https://arstechnica.com/security/2017/02/at-deaths-door-for-years-widely-used-sha1-function-is-now-dead/
> (not a bit of hyperbole in that headline, right? )  Maybe it's a bit
> premature to call it 'dead' but it is definitely in its death rattles.
>
> Google is scheduled to release the source code to produce arbitrary
> "identical-prefix" collisions of SHA-1 hashes in three months.  You need
> about $110,000 worth of compute time to pull off the attack, and that
> number will go down.  We're basically at the same place now with SHA-1
> as we were in 2010 with MD5.
>
> The full paper can be read at https://shattered.io/static/shattered.pdf
>
> And an interesting discussion on git's potential handling of a SHA-1
> collision on a blob is at
> https://stackoverflow.com/questions/9392365/how-would-git-handle-a-sha-1-collision-on-a-blob
>
>
> It may not be urgent, but it's not ridiculous.
>

I think the issue is that you not only have to create a trojan file that 
matches the same hash, but you have to create a trojan file that matches 
the same hash and doesn't break compiling.

Maybe you could do that by padding the file in a comment, but I suspect 
it would be extremely difficult to pull off.

Bottom line is git needs to move to sha256 but I do not believe there is 
any present danger.

I'd be more worried about fraudulently issued TLS certs combined with a 
DNS cache attack when doing a git checkout. That would be easier to 
easier to pull off.