Re: [fossil-users] Proposed roadmap for Fossil 2.0

[Tony Papadimitriou]

-Original Message- 
From: Warren Young

On Feb 26, 2017, at 6:34 PM, Tony Papadimitriou  wrote:

how is it possible for someone to inject a 'bad' file with the same SHA1 
as a 'good' file already in the repo?
Your attacker could be MITM’d into the sync stream.  I gave an example 
requiring only the current SHA-1 collision technology in my first reply in 
the other thread:


So now HTTPS is also broken?


The only ways I can imagine
That’s because you aren’t a highly motivated, highly resourced, highly 
trained black hat.  But such people do exist.


I was implying 'practical' ways, not theoretical.  Now, if Google wants to 
use its billions to break my repo, they may do it, but it would be easier 
for them to try to buy it from me for much less!
So, do you actually know of some other practical ways, or just looking to 
make conversation?


I believe it will be really-really difficult (for the foreseeable future 
at least) for someone to come up with a 'bad' file with both SHA1 and MD5 
being the same.
Given that an MD5 collision costs less than 65 cents US to create these 
days,[3] I think your premise is flawed.
You think, I think, who cares?  Can you prove your point by providing such a 
collision while we're still alive?


Yes, creating a collision in both MD5 and SHA-1 is probably more expensive 
than the addition of the two (US $10.65) but I don’t think you can say 
that MD5 is adding meaningful security here.

MD5 is broken, broken, broken.[4]


So, if I give you a random piece of source code you (or your rich friends) 
can create a matching paired-SHA1-MD5 alternate version (while we're still 
alive)?

You would probably make bigger headlines than Google is making right now.


One would still need to match both SHA1 and MD5 to inject -- not easy!



Argument from incredulity.[5]

Ditto! (Or prove how easy it is!)

may introduce (an avalanche[?] of) bugs, and possibly even risk the 
integrity of our current repos until fully bug-free.
Have avalanches of bugs been a notable hallmark of Fossil and SQLite, in 
your experience?
Past success rates do not guarantee future ones (slightly modified from a 
bank fine print warning).


(I for one would be reluctant to try it for actual work until enough 
other people have used it for some time without problems.)
That’s why the SQLite project dogfoods trunk Fossil, and drh encourages us 
end users to use Fossil from trunk, too.  By the time Fossil 2.0 is 
released, it *will* be well-tested, both formally and informally.
Actually, it's quite common that trunk fossil uses alpha and beta versions 
of SQLite3 for the benefit of test-driving SQLite3.  So, regardless any 
assurances to the contrary, it's still a bit risky.


you can't really get the whole population to switch at the exact same 
time.

We have decades of experience managing such problems.

But ... you are so Young. :)

Less arrogant people with decades of experience also created MD5, SHA1, ... 
Not a very comforting argument at this point, is it?


___
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] Google Security Blog: Announcing the first SHA1 collision

[K. Fossil user]

Hello,
I can't believe that a so called community manager (Warren) could say theses 
...  :D
I assume that most of you have read Warren Stuff ?
1/ Hey Warren, you know nothing about security software so don't speak about 
it. :-|

2/ CentOS does not need any advice from you : they know their stuff.a) SHA 
algorithm is not an issue when it is more a test for integrity such as MD5 for 
files than anything else.b) You are like a kid who focuses on ONE thing when 
people like me are focusing in MANY things even when it comes to ONE subject.c) 
CentOS uses many tools to know who is sending what.You could force people to 
follow some procedures to be allowed to put a precise info into a specific 
server :
Say, you can ask the guy to use SSH first to connect, and only after he could 
work : no GPG, nothing else needed...I don't even talk about port knocking...
So they can rely on ONLY SHA1 if they want that, this is not an issue at all !
So YOUR sentence "it’ll be a problem if git.centos.org is still relying on SHA1 
hashes" IS NOT RELEVANT.
3/>"Point #2 is also questionable.  Torvalds is assuming that any collision 
attack on a Git"
Really ? As I understand Fossil points (security etc) are not seriously 
questionable [for you] ... but Linus point is ? Are you kidding ?
MY assumption is that Linus would like that a guy such as a Fossil Team guy, 
could understand that it is NOT that hard to make some changes with the SHA 
algorithm...

In another word :

4/ When you say that plans are easy but execution is hard ... You miss the 
point.a) Plans are necessary for serious project.b) Plans done, execution is 
not that hard : it may take time but it is not that hard.c) Appropriate tools 
are needed to achieve plans in time and expectations...
Serious project = Plans ! OK ?

If for you SHA1 is not a serious project, then I would like you to explain it 
to us... :D
5/ All this said :I've noticed that there are too much details in Linus Torvald 
discuss. I suppose that he was thinking about guys like you Warren ?You know 
the guy that don't get it. :-)
  
Regards

K.

  De : Warren Young 
 À : Fossil SCM user's discussion  
 Envoyé le : Lundi 27 février 2017 18h10
 Objet : Re: [fossil-users] Google Security Blog: Announcing the first SHA1 
collision
   
On Feb 26, 2017, at 2:58 PM, Stephan Beal  wrote:
> 
> just FYI, Linus' own words on the topic, posted yesterday:
> 
> https://plus.google.com/u/0/+LinusTorvalds/posts/7tp2gYWQugL

Point #1 misses the fact that people *do* rely on Git hashes for security.  
Maybe they’re not “supposed” to, but they do.

For example, the CentOS sources are published through Git these days, rather 
than as a pile of potentially-signed SRPM files.  This means the only assurance 
you have that the content checked into Git hasn’t been tampered with is that 
the hashes are consistent.

(I randomly inspected one of their repos, and it doesn’t use GPG signed 
commits, so the hashes are all you’ve got.)

This is adequate security today, but once bad actors can do these SHA1 attacks 
inexpensively, it’ll be a problem if git.centos.org is still relying on SHA1 
hashes.


Point #2 is also questionable.  Torvalds is assuming that any collision attack 
on a Git checkin will be detectable because of the random noise you have to 
insert into both instances to make them match.

Except that you don’t have to do it with random noise.

Thought experiment time: Given that it is now mature technology to be able to 
react to a useful subset of the spoken English language either over a crappy 
cell phone connection or via shouting at a microphone in a canister in the next 
room, complete with query chaining (e.g. Google Now, Amazon Echo, etc.) how 
much more difficult is it to write an “AI” that can automatically generate 
sane-looking but harmless C code in the middle of a pile of other C code to 
fuzz its data bits?

I have no training in AI type stuff, but I think I could do a pretty decent job 
just by feeding a large subset of GitHub into a Markov chain model.  Now 
imagine what someone with training, motivation, and resources could do.

Or, don't imagine.  Just go read the Microsoft Research paper on DeepCoder:

  https://news.ycombinator.com/item?id=13720580

I suspect there are parts of the Linux kernel sources that are 
indistinguishable from the output of a Markov chain model. :)  *Someone* 
allowed those patches to be checked in.


As for his point #3, he just offers it without support.  He says there’s a 
plan.  Well, we have a plan, too.  Plans are easy.  Execution is the hard part.
___
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

Re: [fossil-users] Proposed roadmap for Fossil 2.0

[Warren Young]

On Feb 26, 2017, at 6:34 PM, Tony Papadimitriou  wrote:
> 
> how is it possible for someone to inject a 'bad' file with the same SHA1 as a 
> 'good' file already in the repo?

Your attacker could be MITM’d into the sync stream.  I gave an example 
requiring only the current SHA-1 collision technology in my first reply in the 
other thread:

https://news.ycombinator.com/item?id=13715887

As for the difficulty of MITM’ing your sync connection, are your Fossil servers 
all behind strong TLS proxies?  If not, your Fossil sync streams pretty 
trivially MITM-able.  And if you do use strong TLS, are you sure there are no 
TLS-busting middleboxes[1] or broken antimalware tools[2] in the computer 
networks at either end of the connection?  


[1]: https://en.wikipedia.org/wiki/Middlebox
[2]: https://goo.gl/37H7pN

> The only ways I can imagine

That’s because you aren’t a highly motivated, highly resourced, highly trained 
black hat.  But such people do exist.

> how urgent is the need to transition away from SHA1?

If we could magically upgrade all of the Fossil clients in the world, we could 
wait until just before the sky actually begins to fall.  That event is likely 
years out.

If drh actually manages to ship a fix for this by Easter — aggressive, but 
doable — then we’ll still be seeing Fossil 1.x on a fair number of systems on 
Easter of 2022, by which time the current attack could be either 5-10x faster 
or 5-10x cheaper, the factor depending on whether there are further 
breakthroughs in that time.  I think we should count on 10x and be pleasantly 
surprised if it’s “only” 5x.

Moore’s Law may be running out of steam for general purpose computing, but not 
for embarrassingly parallel applications like hash collision searching.

> I believe it will be really-really difficult (for the foreseeable future at 
> least) for someone to come up with a 'bad' file with both SHA1 and MD5 being 
> the same.

Given that an MD5 collision costs less than 65 cents US to create these 
days,[3] I think your premise is flawed.

Yes, creating a collision in both MD5 and SHA-1 is probably more expensive than 
the addition of the two (US $10.65) but I don’t think you can say that MD5 
is adding meaningful security here.

MD5 is broken, broken, broken.[4]


[3]: https://natmchugh.blogspot.com/2015/02/create-your-own-md5-collisions.html
[4]: https://eprint.iacr.org/2013/170.pdf

> Don't tell me MD5 is broken.

MD5 is broken. :)

> One would still need to match both SHA1 and MD5 to inject -- not easy!

Argument from incredulity.[5]


[5]: http://rationalwiki.org/wiki/Argument_from_incredulity

> may introduce (an avalanche[?] of) bugs, and possibly even risk the integrity 
> of our current repos until fully bug-free.

Have avalanches of bugs been a notable hallmark of Fossil and SQLite, in your 
experience?

> (I for one would be reluctant to try it for actual work until enough other 
> people have used it for some time without problems.)

That’s why the SQLite project dogfoods trunk Fossil, and drh encourages us end 
users to use Fossil from trunk, too.  By the time Fossil 2.0 is released, it 
*will* be well-tested, both formally and informally.

> you can't really get the whole population to switch at the exact same time.

We have decades of experience managing such problems.  This is known tech.  We 
don’t need to invent any new wheels here.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Web page access permissions

[Richard Gibson]

Hello

I am trying to set up Fossil to serve as a web server. I am having
difficulty granting just plain read access to anonymous users whilst
hosting my pages in wiki format within trunk. I do not want to put my pages
in the wiki section because I do not want to offer history views of them.

Within /setup_config I have configured my index page to be:
  /doc/trunk/www/index.wiki

This is a file within trunk that is a simple HTML page.

Within /setup_access I have set public pages to be:
  /doc/trunk/www/*

I have default privileges set to:
  v

I understand that v corresponds to the developer/UID 4. I have granted this
capability i, because if I set default privileges to 'u' (the reader), the
random passer by cannot see the pages that sit under trunk.
Ideally I would like to have reader or nobody access for pages in the doc
section under trunk (so 'u' access) because I would like to grant edit
access to developers (not random passers by!) at a later date.

How can I do this?

Thanks
___
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] Google Security Blog: Announcing the first SHA1 collision

[bch]

On 2/27/17, Warren Young  wrote:
> On Feb 26, 2017, at 2:58 PM, Stephan Beal  wrote:
>>
>> just FYI, Linus' own words on the topic, posted yesterday:
>>
>> https://plus.google.com/u/0/+LinusTorvalds/posts/7tp2gYWQugL
>
> Point #1 misses the fact that people *do* rely on Git hashes for security.
> Maybe they’re not “supposed” to, but they do.
>
> For example, the CentOS sources are published through Git these days, rather
> than as a pile of potentially-signed SRPM files.  This means the only
> assurance you have that the content checked into Git hasn’t been tampered
> with is that the hashes are consistent.

This is a long-standing peeve of mine, which is: a repository is not a
release. If this is how CentOS does distribution, I'd argue they have
more of a systemic problem than a technical one.

-bch

>
> (I randomly inspected one of their repos, and it doesn’t use GPG signed
> commits, so the hashes are all you’ve got.)
>
> This is adequate security today, but once bad actors can do these SHA1
> attacks inexpensively, it’ll be a problem if git.centos.org is still relying
> on SHA1 hashes.
>
>
> Point #2 is also questionable.  Torvalds is assuming that any collision
> attack on a Git checkin will be detectable because of the random noise you
> have to insert into both instances to make them match.
>
> Except that you don’t have to do it with random noise.
>
> Thought experiment time: Given that it is now mature technology to be able
> to react to a useful subset of the spoken English language either over a
> crappy cell phone connection or via shouting at a microphone in a canister
> in the next room, complete with query chaining (e.g. Google Now, Amazon
> Echo, etc.) how much more difficult is it to write an “AI” that can
> automatically generate sane-looking but harmless C code in the middle of a
> pile of other C code to fuzz its data bits?
>
> I have no training in AI type stuff, but I think I could do a pretty decent
> job just by feeding a large subset of GitHub into a Markov chain model.  Now
> imagine what someone with training, motivation, and resources could do.
>
> Or, don't imagine.  Just go read the Microsoft Research paper on DeepCoder:
>
>https://news.ycombinator.com/item?id=13720580
>
> I suspect there are parts of the Linux kernel sources that are
> indistinguishable from the output of a Markov chain model. :)  *Someone*
> allowed those patches to be checked in.
>
>
> As for his point #3, he just offers it without support.  He says there’s a
> plan.  Well, we have a plan, too.  Plans are easy.  Execution is the hard
> part.
> ___
> 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

Re: [fossil-users] Google Security Blog: Announcing the first SHA1 collision

[Warren Young]

On Feb 26, 2017, at 2:58 PM, Stephan Beal  wrote:
> 
> just FYI, Linus' own words on the topic, posted yesterday:
> 
> https://plus.google.com/u/0/+LinusTorvalds/posts/7tp2gYWQugL

Point #1 misses the fact that people *do* rely on Git hashes for security.  
Maybe they’re not “supposed” to, but they do.

For example, the CentOS sources are published through Git these days, rather 
than as a pile of potentially-signed SRPM files.  This means the only assurance 
you have that the content checked into Git hasn’t been tampered with is that 
the hashes are consistent.

(I randomly inspected one of their repos, and it doesn’t use GPG signed 
commits, so the hashes are all you’ve got.)

This is adequate security today, but once bad actors can do these SHA1 attacks 
inexpensively, it’ll be a problem if git.centos.org is still relying on SHA1 
hashes.


Point #2 is also questionable.  Torvalds is assuming that any collision attack 
on a Git checkin will be detectable because of the random noise you have to 
insert into both instances to make them match.

Except that you don’t have to do it with random noise.

Thought experiment time: Given that it is now mature technology to be able to 
react to a useful subset of the spoken English language either over a crappy 
cell phone connection or via shouting at a microphone in a canister in the next 
room, complete with query chaining (e.g. Google Now, Amazon Echo, etc.) how 
much more difficult is it to write an “AI” that can automatically generate 
sane-looking but harmless C code in the middle of a pile of other C code to 
fuzz its data bits?

I have no training in AI type stuff, but I think I could do a pretty decent job 
just by feeding a large subset of GitHub into a Markov chain model.  Now 
imagine what someone with training, motivation, and resources could do.

Or, don't imagine.  Just go read the Microsoft Research paper on DeepCoder:

   https://news.ycombinator.com/item?id=13720580

I suspect there are parts of the Linux kernel sources that are 
indistinguishable from the output of a Markov chain model. :)  *Someone* 
allowed those patches to be checked in.


As for his point #3, he just offers it without support.  He says there’s a 
plan.  Well, we have a plan, too.  Plans are easy.  Execution is the hard part.
___
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] Google Security Blog: Announcing the first SHA1 collision

[Warren Young]

On Feb 26, 2017, at 2:34 PM, Richard Hipp  wrote:
> 
> On 2/23/17, Warren Young  wrote:
>> 
>> I think Fossil is in a much better position to do this sort of migration
>> than, say, Git, due to its semi-centralized nature.
> 
> it is reasonable to argue that Git(Hub) is more centralized than
> Fossil.

Yes, but that’s my point: because so many people use Git in conjunction with 
some large service with many users — not just GitHub, but also BitBucket, 
visualstudio.com, etc. — they can’t as easily change a hash algorithm like this 
because cutting off “only” some small percentage of users means annoying many 
thousands of users.

Whereas with Fossil, few Fossil instances host many Fossil repositories, so 
that the number of users affected by any decision to upgrade to a better hash 
algorithm affects few enough people that in many cases, they can all be 
contacted personally to coordinate the upgrade.

GitHub may have the power to declare a flag day[1] but imagine the hue and cry 
if they tried!

Thus, Git is going to have a very hard time moving away from SHA1.


[1]: https://en.wikipedia.org/wiki/Flag_day_(computing)
___
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] Google Security Blog: Announcing the first SHA1 collision

[Warren Young]

On Feb 26, 2017, at 2:04 PM, Ron W  wrote:
> 
> From: Warren Young 
> 
> > The PHC scheme would allow Fossil to migrate to something stronger in a
> > backwards-compatible fashion:
> 
> The PHC scheme is conceptually good, but is not friendly for use by command 
> line tools

I wasn’t suggesting that the end user of Fossil type PHC-formatted hashes.  
That is an implementation detail which would allow Fossil to migrate to 
something better than SHA1 today, and then to something better than that 
tomorrow, all in a forwards-compatible way.

If I say “fossil up 123abc” in this new world, that should match *any* hash 
whose first 6 digits in hex form are “123abc”, no matter the hash algorithm.  
If it matches one artifact hashed with SHA1 and another hashed with SHA2-256, 
it’s still a “collision” in the Fossil sense, and Fossil will still demand more 
digits to disambiguate it, just as it does today.

If that means we have to modify PHC to encode in hex, that’s fine, because 
Base64 is not the most interesting part of PHC.  The most interesting parts are 
how it encodes the algorithm used, so that the hash is self-documenting.  It 
means you don’t have to memorize (or encode!) imperfect heuristics like “40 hex 
digits == SHA1” because 40 hex digits can also be RIPEMD-160 or SHA3-160.

(The latter is nonstandard, but it’s possible to configure SHA3 to produce it.  
 I assume there are those who have done this on purpose in software where the 
developers want to use a stronger algorithm but can’t resize some fixed-width 
hash field.)
___
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] Proposed roadmap for Fossil 2.0

[Ron Aaron]

  
  

On 27/02/2017 16:14, Richard Hipp
  wrote:


  On 2/26/17, Ron Aaron  wrote:

  

>From a performance standpoint, I would rather see Fossil adopt the
BLAKE2 hash, as it is one of the fastest of the SHA3 finalists, and has
adjustable output hash size.


  
  
Please write and check-in code (on the "fossil-2.0" branch) that
implements BLAKE2 in a manner analogous to the code in sha1.c and
sha3.c.  I suggest a new file named "blake2.c". I will then make it an
option.

What hash length do you want for BLAKE2?  Please make the hash length
for Fossil-BLAKE2 be a multiple of 8 bits and different from 160, 228,
and 256 as those values are already assigned to other hashes.


I wish I could, but I'm so over-committed right now I can't.  Once
my work-load subsides a bit I'll be happy to do that.


  

  Ron Aaron | 
   CTO  Aaron High-Tech, Ltd |
  +1 425.296.0766 / +972 52.652.5543 |
  
GnuPG Key: 91F92EB8


  

___
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] Proposed roadmap for Fossil 2.0

[Richard Hipp]

On 2/26/17, Ron Aaron  wrote:
>
> From a performance standpoint, I would rather see Fossil adopt the
> BLAKE2 hash, as it is one of the fastest of the SHA3 finalists, and has
> adjustable output hash size.
>

Please write and check-in code (on the "fossil-2.0" branch) that
implements BLAKE2 in a manner analogous to the code in sha1.c and
sha3.c.  I suggest a new file named "blake2.c". I will then make it an
option.

What hash length do you want for BLAKE2?  Please make the hash length
for Fossil-BLAKE2 be a multiple of 8 bits and different from 160, 228,
and 256 as those values are already assigned to other hashes.
-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users