On 19 October 2016 at 11:48, Scott Robison <sc...@casaderobison.com> wrote: > Given that it is impossible to predict exactly how one will solve a given > problem (and thus what its hash would be) in advance, the speed of fossil's > default auto sync, the fact that no one has yet demonstrated an effective > real time attack, and the fact that sha1 is not being used for security but > for reliability, sha1 isn't an issue.
When I first found out that fossil only used sha1, I had the same cringe as almost everyone else who first finds out about this, but then after repeatedly hearing there's not a POC, I became less concerned. If sha1 were used in zsf as its checksum, I'd be concerned because that's a file system and there's a larger but still unlikely possibility there could be a collision. W.T.R. security and fossil, I believe fossil uses sha1 for password hashing. That said, I see sha1.c comes from openBSD and netBSD. OpenBSD revision on the sha1.c in fossil shows version 1.9 and openbsd's version has been updated several times to 1.26: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/hash/sha1.c 19 years vs. 13 months. here's the diff: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/hash/sha1.c.diff?r1=1.26&r2=1.9&f=h fossil's sha1.c: https://www.fossil-scm.org/index.html/artifact/67e15d131209fb33 Anyone see anything significant in the latest openbsd version? -- ------- inum: 883510009027723 sip: jungleboo...@sip2sip.info _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users