<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Feb 24, 2017 at 5:27 PM, Ron Garret <span dir="ltr"><<a href="mailto:ron@flownet.com" target="_blank">ron@flownet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>There is an easy short-term mitigation for this: before computing the hash of any object longer than 319 bytes, compute the hash of the first 320 bytes and check if it is <span style="font-family:Monaco">f92d74e3874587aaf443d1db961<wbr>d4e26dde13e9c</span> .  If it is, throw an error.  But of course that will only work until the next SHA1 collision is found.</div></div></blockquote><div><br></div><div>I found another simple fix for git.  I thought it would be really hard, because "SHA1" is a hard-coded call in ~1,000 places.  Instead, just define a new function called sha1.  I've added a BLAKE2b wrapper locally.  It was a tiny change, makes it more secure, and is faster than SHA1.</div><div><br></div><div>Bill</div></div></div></div>