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

Reply via email to