Hi, In this thread I try to: give short answer to what I've read, then I give my opinion, and finally I put some suggests : 1/ Thanks to people who give their opinions and technical point of view in this topic.2/ I know that Git uses sha1, debian uses md5,sha1,sha256 , etc. ...The point is not "is it used?", the point is : is it secure when it is not only used locally ...3/ I've said that xinetd and something like that should not be used for any server, and drh used it in one of his server.4/ OpenBSD have security in mind so OpenBSD sha1 code should be used. However, see if license match.
My assumptions are: 1/ weak server is bad so even a sha512 or higher (does it exists ?) never change anything : you're in big troubles, or you will be in big trouble.2/ If we only use sha1, if people do want sha256, it could not happen. I would like an md5, so I could run it in a slower machine, I suppose. My Suggests : 1/ SHA1 should be OpenBSD source code. 2/ At compilation time options should be :a) default : SHA256 only e.g. no options e.g. --with-sha=default e.g. --with-sha=sha256b) old behavior : SHA1 and SHA256 e.g. --with-sha=compatibility e.g. --with-sha=sha1,sha256 e.g. --with-sha=before1.37-rock-solid (:D LOL) c) SHA1 only (Why not) e.g. --with-sha=legacy e.g. --with-sha=sha1d) MD5 only (why not) e.g. --with-sha=md5e) public server e.g. --with-sha=public e.g. --with-sha=sha1,sha256,sha512f) local only e.g. --with-sha=local e.g. --with-sha=md5g) SHA1 is OpenBSD e.g. --sha1-is-openbsd e.g. --sha1-code=openbsd,netbsd 3/ Configuration example :commit-allowed-sha : md5,sha256commit-denied-sha : sha1commit-public-sha=sha1,sha256commit-priority : deny, allowed, nonefossil-exchange-priority : sha256, sha1, noneSHA1=OpenBSD etc. 4/ Fossil status should show something like :SHA available are :- SHA1 (release number) OpenBSD - SHA256 (release number) (default)-etc. 5/ When one runs it :fossil (some options) --commit-sha=md5,sha1,sha256fossil (some options) --commit-sha=publicfossil (some options) --commit-sha=myProfile # Yes it should be possible! etc. 6/ In the fossil options when a browser is used, a tab should be used for SHA only.Everything should be seen there :a) Who could see what.b) Who could use what.c) What is the status of the configuration : server, Fossil file, etc. All these need a poll. Why ?1/ Options name should be discussed.2/ Options real behavior should be known (is SHA1 OpenBSD ?) 3/ What are legacy and compatibility definitions for Fossil user ? 4/ default option should be clear. etc. Ah ! I was asked what are my unmet needs.I've said "none at this time: I don't want to talk about that".However, I think that THIS unmet need (sha options) are unmet needs that I do want as soon as possible, please ! Best Regards K. De : Scott Robison <sc...@casaderobison.com> À : Fossil SCM user's discussion <fossil-users@lists.fossil-scm.org> Envoyé le : Mercredi 19 octobre 2016 18h48 Objet : Re: [fossil-users] on sha1 as a hash On Wed, Oct 19, 2016 at 2:36 AM, Aldo Nicolas Bruno <ovenpa...@pizzahack.eu> wrote: Better question can be, how fossil manage collisions? Fossil rejects new artifacts with matching hashes, working on the assumption that it already has the blob. The only way someone could hope to exploit this for malicious purposes is: 1. Discover some fossil user has created a commit with an artifact having a given hash X.2. Quickly create another artifact with that same hash.3. Push it to other copies of the same repository before the original fossil user is able to push his copy. In both the cases of git and fossil, it seems to me that hash collisions (deliberate or coincidental) are a race condition. Whoever pushes to other repositories first wins. 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. Even if someone found an effective real time attack that could generate a collision, they then have the problem of not just finding a collision, but a collision that will be close enough to the original that the primary functionality wasn't broken (in the case of tracking source code, arguably the most common case). Really, from this POV, fossil and git are both just fine. It's far more likely that someone will compromise a server with a weak password and completely replace the good repo with a bad repo, or just host a fork that looks legit and get people to pull from that instead. -- Scott Robison _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users