Re: [fossil-users] on sha1 as a hash

[Martin Gagnon]

> Le 20 oct. 2016 à 02:57, Luca Ferrari  a écrit :
> 
> On Wed, Oct 19, 2016 at 10:36 AM, Aldo Nicolas Bruno
>  wrote:
>> Better question can be, how fossil manage collisions?
> 
> Just a side note: according to v1.31
>  the repository
> can now show its own collisions, as in
> . As far as I understand
> the collision is simply kept and marked as ambiguos.
> 
> Luca
> 

Those are collisions of sha1 prefix, using different lengths. It has nothing to 
do with a collision of the integral hash.

-- 
Martin G.

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] on sha1 as a hash

[Luca Ferrari]

On Wed, Oct 19, 2016 at 10:36 AM, Aldo Nicolas Bruno
 wrote:
> Better question can be, how fossil manage collisions?

Just a side note: according to v1.31
 the repository
can now show its own collisions, as in
. As far as I understand
the collision is simply kept and marked as ambiguos.

Luca
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] on sha1 as a hash

[K. Fossil user]

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


   ___

Re: [fossil-users] on sha1 as a hash

[jungle Boogie]

On 19 October 2016 at 14:19, jungle Boogie  wrote:
> 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:

Meanwhile netbsd hasn't made any changes to sha1.c in 6 years, so it
has the same version as what's in fossil:
http://cvsweb.netbsd.org/bsdweb.cgi/src/common/lib/libc/hash/sha1/sha1.c?only_with_tag=MAIN


-- 
---
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

Re: [fossil-users] on sha1 as a hash

[jungle Boogie]

On 19 October 2016 at 11:48, Scott Robison  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=1.9=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

Re: [fossil-users] on sha1 as a hash

[Scott Robison]

On Wed, Oct 19, 2016 at 2:36 AM, Aldo Nicolas Bruno 
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

Re: [fossil-users] on sha1 as a hash

[Aldo Nicolas Bruno]

On 19/10/2016 02:45, K. Fossil user wrote:
> Hi,
>
> 1/ Does Fossil use SHA1 ?
> Oo
> Too bad if it is.
> At least I expect that we've got a choice : sha256, sha512, etc. ...
from https://en.wikipedia.org/wiki/SHA-1#Data_integrity

Revision control 
systems such as Git 
and Mercurial  use SHA-1 not
for security but for ensuring that the data has not changed due to
accidental corruption. Linus Torvalds
 said about Git:

If you have disk corruption, if you have DRAM corruption, if you
have any kind of problems at all, Git will notice them. It's not a
question of /if/, it's a guarantee. You can have people who try to
be malicious. They won't succeed. [...] Nobody has been able to
break SHA-1, but the point is the SHA-1, as far as Git is concerned,
isn't even a security feature. It's purely a consistency check. The
security parts are elsewhere, so a lot of people assume that since
Git uses SHA-1 and SHA-1 is used for cryptographically secure stuff,
they think that, Okay, it's a huge security feature. It has nothing
at all to do with security, it's just the best hash you can get. [...]
I guarantee you, if you put your data in Git, you can trust the fact
that five years later, after it was converted from your hard disk to
DVD to whatever new technology and you copied it along, five years
later you can verify that the data you get back out is the exact
same data you put in. [...]
One of the reasons I care is for the kernel, we had a break in on
one of the BitKeeper sites where people tried to corrupt the kernel
source code repositories.^[18]
 However Git does
not require the second preimage resistance
 of SHA-1
as a security feature, since it will always prefer to keep the
earliest version of an object in case of collision, preventing an
attacker from surreptitiously overwriting files.^[19]
 


Better question can be, how fossil manage collisions?

Best regards

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] on sha1 as a hash

[K. Fossil user]

Hi,
1/ Does Fossil use SHA1 ?OoToo bad if it is.At least I expect that we've got a 
choice : sha256, sha512, etc. ...

2/ However, when people use Fossil in a local PC, even MD5 should not be an 
issue.3/ Thanks for this reminder. 
 
Best Regards

K.

  De : bch 
 À : fossil-users@lists.fossil-scm.org 
 Envoyé le : Mardi 18 octobre 2016 22h23
 Objet : [fossil-users] on sha1 as a hash
   
https://news.ycombinator.com/item?id=12737535
___
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