On Oct 28, 2015, at 11:40 PM, Scott Robison <[email protected]> wrote: > > If fossil didn't say it used SHA1 to generate artifact IDs, I don't think > anyone would care how it generated IDs.
+1. It should just say “artifact ID”, or “checkin ID”. > In fact, the "easiest" way to getting people to use malicious software is to > host a compromised repository and convince people to use it instead of the > "blessed" repository. Anyone who thinks that’s unlikely probably missed the XcodeGhost news: http://www.macrumors.com/2015/09/20/xcodeghost-chinese-malware-faq/ > Ultimately, one can chase hash algorithms forever trying to create some > ultimately secure ideal. We have 42 years of history — dating from the addition of crypt(3) to Unix V3 in 1973 — telling us that hash algorithms have a finite lifetime, and that we need a way to replace them after their useful years of service life are spent: http://www.cs.technion.ac.il/~cs236350/Material/unix-password-security-ten.pdf The argument over whether Fossil is vulnerable today or if not how long it will take before it is vulnerable is a side issue next to the fact that Fossil wasn’t designed to make replacing SHA-1 straightforward. If it were easy, we could just swap in something better out of an abundance of caution and go on our way. Those arguing for replacement of SHA-1 usually come from a world where such swaps are easy: /etc/shadow, X.509 certs, web pages reporting binary package sums, etc. > the odds of a non-malicious collision are so close to zero that those odds > might as well be zero. I’ll bet there are a whole lot of people who would love to get some evil code into pretty much every smartphone in the world by hacking the SQLite code repo. That’s a powerful motivation. Don’t underestimate it. _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
