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
