[prev in list] [next in list] [prev in thread] [next in thread]
List: fossil-users
Subject: Re: [fossil-users] on sha1 as a hash
From: "K. Fossil user" <ticketpersonnal-fossil () yahoo ! fr>
Date: 2016-10-20 1:46:32
Message-ID: 1209588585.9501.1476927992602 () mail ! yahoo ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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 <scott@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 <ovenpasta@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
[Attachment #5 (text/html)]
<html><head></head><body><div style="color:#000; background-color:#fff; \
font-family:HelveticaNeue-Light, Helvetica Neue Light, Helvetica Neue, Helvetica, \
Arial, Lucida Grande, sans-serif;font-size:16px"><div \
id="yui_3_16_0_ym19_1_1476923821604_7901"><span>Hi,</span></div><div \
id="yui_3_16_0_ym19_1_1476923821604_8063"><br></div><div dir="ltr">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 :</div><div dir="ltr"><br><span></span></div><div \
id="yui_3_16_0_ym19_1_1476923821604_8065"><span \
id="yui_3_16_0_ym19_1_1476923821604_8064">1/ Thanks to people who give their opinions \
and technical point of view in this topic.</span></div><div \
id="yui_3_16_0_ym19_1_1476923821604_7905"><div \
id="yui_3_16_0_ym19_1_1476923821604_8203">2/ I know that Git uses sha1, debian uses \
md5,sha1,sha256 , etc. ...</div><div id="yui_3_16_0_ym19_1_1476923821604_8051">The \
point is not "<i>is it used?</i>", the point is : is it secure when it is not only \
used locally ...</div><div id="yui_3_16_0_ym19_1_1476923821604_8204">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.</div><div dir="ltr" \
id="yui_3_16_0_ym19_1_1476923821604_8202">4/ OpenBSD have security in mind so OpenBSD \
sha1 code should be used. However, see if license match.<br></div><div \
id="yui_3_16_0_ym19_1_1476923821604_8264"><br></div><div \
id="yui_3_16_0_ym19_1_1476923821604_8050">My assumptions are:</div><div \
id="yui_3_16_0_ym19_1_1476923821604_8205" dir="ltr"><br></div><div \
id="yui_3_16_0_ym19_1_1476923821604_9586" dir="ltr">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.</div><div id="yui_3_16_0_ym19_1_1476923821604_8206" \
dir="ltr">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.</div><div \
id="yui_3_16_0_ym19_1_1476923821604_8207" dir="ltr"><br></div><div \
id="yui_3_16_0_ym19_1_1476923821604_8481" dir="ltr">My Suggests :</div><div \
id="yui_3_16_0_ym19_1_1476923821604_9532" dir="ltr"><br></div><div \
id="yui_3_16_0_ym19_1_1476923821604_8494" dir="ltr">1/ SHA1 should be OpenBSD source \
code.</div><div id="yui_3_16_0_ym19_1_1476923821604_8507" dir="ltr"><br></div><div \
id="yui_3_16_0_ym19_1_1476923821604_9247" dir="ltr">2/ At compilation time options \
should be :</div><div id="yui_3_16_0_ym19_1_1476923821604_8552" dir="ltr">a) default \
: SHA256 only e.g. no options e.g. --with-sha=default e.g. \
--with-sha=sha256</div><div id="yui_3_16_0_ym19_1_1476923821604_8553" dir="ltr">b) \
old behavior : SHA1 and SHA256 e.g. --with-sha=compatibility e.g. \
--with-sha=sha1,sha256</div><div id="yui_3_16_0_ym19_1_1476923821604_9363" dir="ltr"> \
e.g. --with-sha=before1.37-rock-solid (:D LOL)<br></div><div \
id="yui_3_16_0_ym19_1_1476923821604_8566" dir="ltr">c) SHA1 only (Why not) e.g. \
--with-sha=legacy e.g. --with-sha=sha1</div><div \
id="yui_3_16_0_ym19_1_1476923821604_8579" dir="ltr">d) MD5 only (why not) e.g. \
--with-sha=md5</div><div id="yui_3_16_0_ym19_1_1476923821604_8580" dir="ltr">e) \
public server e.g. --with-sha=public e.g. --with-sha=sha1,sha256,sha512</div><div \
id="yui_3_16_0_ym19_1_1476923821604_8581" dir="ltr">f) local only e.g. \
--with-sha=local e.g. --with-sha=md5</div><div \
id="yui_3_16_0_ym19_1_1476923821604_10282" dir="ltr">g) SHA1 is OpenBSD e.g. \
--sha1-is-openbsd e.g. --sha1-code=openbsd,netbsd</div><div \
id="yui_3_16_0_ym19_1_1476923821604_8703" dir="ltr"><br></div><div \
id="yui_3_16_0_ym19_1_1476923821604_8702" dir="ltr">3/ Configuration example \
:</div><div id="yui_3_16_0_ym19_1_1476923821604_8853" dir="ltr">commit-allowed-sha : \
md5,sha256</div><div id="yui_3_16_0_ym19_1_1476923821604_8731" \
dir="ltr">commit-denied-sha : sha1</div><div \
id="yui_3_16_0_ym19_1_1476923821604_8756" \
dir="ltr">commit-public-sha=sha1,sha256</div>commit-priority : deny, allowed, \
none<div id="yui_3_16_0_ym19_1_1476923821604_9932" dir="ltr">fossil-exchange-priority \
: sha256, sha1, none</div><div id="yui_3_16_0_ym19_1_1476923821604_10318" \
dir="ltr">SHA1=OpenBSD<br></div><div id="yui_3_16_0_ym19_1_1476923821604_9927" \
dir="ltr">etc.</div><div id="yui_3_16_0_ym19_1_1476923821604_9799" \
dir="ltr"><br></div><div id="yui_3_16_0_ym19_1_1476923821604_8718" dir="ltr">4/ \
Fossil status should show something like :</div><div \
id="yui_3_16_0_ym19_1_1476923821604_8601" dir="ltr">SHA available are :</div><div \
id="yui_3_16_0_ym19_1_1476923821604_8705" dir="ltr">- SHA1 (release number) \
OpenBSD<br></div><div id="yui_3_16_0_ym19_1_1476923821604_8602" dir="ltr">- SHA256 \
(release number) (default)</div><div id="yui_3_16_0_ym19_1_1476923821604_8603" \
dir="ltr">-etc.</div><div id="yui_3_16_0_ym19_1_1476923821604_8604" \
dir="ltr"><br></div><div id="yui_3_16_0_ym19_1_1476923821604_8605" dir="ltr">5/ When \
one runs it :</div><div id="yui_3_16_0_ym19_1_1476923821604_8673" dir="ltr">fossil \
(some options) --commit-sha=md5,sha1,sha256</div><div \
id="yui_3_16_0_ym19_1_1476923821604_8638" dir="ltr">fossil (some options) \
--commit-sha=public</div><div id="yui_3_16_0_ym19_1_1476923821604_9957" \
dir="ltr">fossil (some options) --commit-sha=myProfile # Yes it should be \
possible!<br></div><div id="yui_3_16_0_ym19_1_1476923821604_8639" dir="ltr">etc.<br \
id="yui_3_16_0_ym19_1_1476923821604_8640"></div><div \
id="yui_3_16_0_ym19_1_1476923821604_8201" dir="ltr"><br></div><div \
id="yui_3_16_0_ym19_1_1476923821604_9174" dir="ltr">6/ In the fossil options when a \
browser is used, a tab should be used for SHA only.</div><div \
id="yui_3_16_0_ym19_1_1476923821604_9056" dir="ltr">Everything should be seen there \
:</div><div id="yui_3_16_0_ym19_1_1476923821604_9055" dir="ltr">a) Who could see \
what.</div><div id="yui_3_16_0_ym19_1_1476923821604_9029" dir="ltr">b) Who could use \
what.</div><div id="yui_3_16_0_ym19_1_1476923821604_9042" dir="ltr">c) What is the \
status of the configuration : server, Fossil file, etc.<br></div><div \
id="yui_3_16_0_ym19_1_1476923821604_9028" dir="ltr"><br></div><div \
id="yui_3_16_0_ym19_1_1476923821604_8878" dir="ltr">All these need a poll. Why \
?</div><div id="yui_3_16_0_ym19_1_1476923821604_8951" dir="ltr">1/ Options name \
should be discussed.</div><div id="yui_3_16_0_ym19_1_1476923821604_8952" dir="ltr">2/ \
Options real behavior should be known (is SHA1 OpenBSD ?)<br></div><div \
id="yui_3_16_0_ym19_1_1476923821604_9094" dir="ltr">3/ What are <i \
id="yui_3_16_0_ym19_1_1476923821604_9773">legacy</i> and <i \
id="yui_3_16_0_ym19_1_1476923821604_9147">compatibility</i> definitions for Fossil \
user ?<br></div><div id="yui_3_16_0_ym19_1_1476923821604_9095" dir="ltr">4/ default \
option should be clear.<br></div><div id="yui_3_16_0_ym19_1_1476923821604_9096" \
dir="ltr">etc.</div><div id="yui_3_16_0_ym19_1_1476923821604_9176" \
dir="ltr"><br></div><div id="yui_3_16_0_ym19_1_1476923821604_9743" dir="ltr">Ah ! I \
was asked what are my unmet needs.</div><div \
id="yui_3_16_0_ym19_1_1476923821604_9741" dir="ltr">I've said "<i>none at this time: \
I don't want to talk about that</i>".</div><div \
id="yui_3_16_0_ym19_1_1476923821604_9740" dir="ltr">However, I think that THIS unmet \
need (sha options) are unmet needs that I do want as soon as possible, please \
!<br></div></div><div id="yui_3_16_0_ym19_1_1476923821604_7843" \
class="signature"><div id="yui_3_16_0_ym19_1_1476923821604_9739"><br></div><div \
id="yui_3_16_0_ym19_1_1476923821604_9756"><br></div>Best Regards<br><br>K.</div><div \
id="yui_3_16_0_ym19_1_1476923821604_7842" class="qtdSeparateBR"><br><br></div><div \
style="display: block;" id="yui_3_16_0_ym19_1_1476923821604_7835" \
class="yahoo_quoted"> <div id="yui_3_16_0_ym19_1_1476923821604_7834" \
style="font-family: HelveticaNeue-Light, Helvetica Neue Light, Helvetica Neue, \
Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div \
id="yui_3_16_0_ym19_1_1476923821604_7833" style="font-family: HelveticaNeue, \
Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div \
id="yui_3_16_0_ym19_1_1476923821604_7832" dir="ltr"> <font \
id="yui_3_16_0_ym19_1_1476923821604_7841" face="Arial" size="2"> <hr \
id="yui_3_16_0_ym19_1_1476923821604_9161" size="1"> <b><span \
style="font-weight:bold;">De :</span></b> Scott Robison \
<scott@casaderobison.com><br> <b><span style="font-weight: \
bold;">À :</span></b> Fossil SCM user's discussion \
<fossil-users@lists.fossil-scm.org> <br> <b><span style="font-weight: \
bold;">Envoyé le :</span></b> Mercredi 19 octobre 2016 18h48<br> <b><span \
style="font-weight: bold;">Objet :</span></b> Re: [fossil-users] on sha1 as a \
hash<br> </font> </div> <div id="yui_3_16_0_ym19_1_1476923821604_9129" \
class="y_msg_container"><br><div id="yiv9178228120"><div \
id="yui_3_16_0_ym19_1_1476923821604_9128"><div \
id="yui_3_16_0_ym19_1_1476923821604_9127" dir="ltr"><div \
id="yui_3_16_0_ym19_1_1476923821604_9126" class="yiv9178228120gmail_extra"><div \
class="yiv9178228120yqt4429904354" id="yiv9178228120yqtfd06401"><div \
id="yui_3_16_0_ym19_1_1476923821604_9125" class="yiv9178228120gmail_quote">On Wed, \
Oct 19, 2016 at 2:36 AM, Aldo Nicolas Bruno <span dir="ltr"><<a rel="nofollow" \
shape="rect" ymailto="mailto:ovenpasta@pizzahack.eu" target="_blank" \
href="mailto:ovenpasta@pizzahack.eu">ovenpasta@pizzahack.eu</a>></span> wrote:<br \
clear="none"><blockquote id="yui_3_16_0_ym19_1_1476923821604_9637" \
class="yiv9178228120gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex;">
<div id="yui_3_16_0_ym19_1_1476923821604_9636"><span class="yiv9178228120">
</span><div id="yui_3_16_0_ym19_1_1476923821604_9635" \
class="yiv9178228120m_3924750874281501004moz-cite-prefix">Better question can be, how \
fossil manage collisions? <br clear="none"></div></div></blockquote><div><br \
clear="none"></div><div id="yui_3_16_0_ym19_1_1476923821604_9618">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:</div><div><br clear="none"></div><div \
id="yui_3_16_0_ym19_1_1476923821604_9620">1. Discover some fossil user has created a \
commit with an artifact having a given hash X.</div><div \
id="yui_3_16_0_ym19_1_1476923821604_9124">2. Quickly create another artifact with \
that same hash.</div><div id="yui_3_16_0_ym19_1_1476923821604_9134">3. Push it to \
other copies of the same repository before the original fossil user is able to push \
his copy.</div><div id="yui_3_16_0_ym19_1_1476923821604_9132"><br \
clear="none"></div><div id="yui_3_16_0_ym19_1_1476923821604_9133">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.</div><div><br \
clear="none"></div><div>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.</div><div \
id="yui_3_16_0_ym19_1_1476923821604_9625"><br clear="none"></div><div \
id="yui_3_16_0_ym19_1_1476923821604_9633">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).</div><div><br clear="none"></div><div>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.</div><div><br clear="none"></div></div></div>-- <br clear="none"><div \
id="yui_3_16_0_ym19_1_1476923821604_9623" class="yiv9178228120gmail_signature"><div \
id="yui_3_16_0_ym19_1_1476923821604_9622" dir="ltr">Scott Robison<div \
class="yiv9178228120yqt4429904354" id="yiv9178228120yqtfd61807"><div \
id="yui_3_16_0_ym19_1_1476923821604_9621"><br \
clear="none"></div></div></div></div><div class="yiv9178228120yqt4429904354" \
id="yiv9178228120yqtfd05312"> </div></div></div></div></div><br><div \
class="yqt4429904354" \
id="yqtfd57505">_______________________________________________<br \
clear="none">fossil-users mailing list<br clear="none"><a shape="rect" \
ymailto="mailto:fossil-users@lists.fossil-scm.org" \
href="mailto:fossil-users@lists.fossil-scm.org">fossil-users@lists.fossil-scm.org</a><br \
clear="none"><a shape="rect" \
href="http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users" \
target="_blank">http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users</a><br \
clear="none"></div><br><br></div> </div> </div> </div></div></body></html>
[Attachment #6 (text/plain)]
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic