Re: [9fans] SHA-1 collision and venti

2017-02-26 Thread Jules Merit
there is a backdoor when a score of 4, what data produces it i have no idea.

On Sun, Feb 26, 2017 at 9:25 AM, Bakul Shah  wrote:

> https://arstechnica.com/security/2017/02/watershed-
> sha1-collision-just-broke-the-webkit-repository-others-may-follow/
>
> https://shattered.io/static/shattered.pdf
>
> Venti is similarly corruptible, right? Since the checksum is over just the
> content. If you downloaded https://shattered.io/static/shattered-1.pdf
>  and
> https://shattered.io/static/shattered-2.pdf, venti would lose the
> contents of one.
>


[9fans] Proof of concept inertial scrolling on macOS with devdraw/acme

2017-02-26 Thread marius a. eriksen
It’s surprisingly pleasant to use (with a Mac laptop, a Magic Trackpad or
aMagic Mouse)

Demo here: https://www.youtube.com/watch?v=1XJFJ4coS48=youtu.be

commit d782c880d4ca30fcacddfbab298dad82fe8277c3
Author: marius a. eriksen 
Date:   Sat Feb 25 21:48:50 2017 -0800

devdraw/acme: support for inertial scrolling on macOS.

diff --git a/src/cmd/acme/acme.c b/src/cmd/acme/acme.c
index b471a29..d84322f 100644
--- a/src/cmd/acme/acme.c
+++ b/src/cmd/acme/acme.c
@@ -614,6 +614,14 @@ mousethread(void *v)
  }
  /* scroll buttons, wheels, etc. */
  if(w != nil && (m.buttons & (8|16))){
+ if((m.buttons >> 2) != 0){
+ winlock(w, 'M');
+ t->eq0 = ~0;
+ xtextscroll(t, m.buttons>>2);
+ winunlock(w);
+ goto Continue;
+ }
+
  if(m.buttons & 8)
  but = Kscrolloneup;
  else
diff --git a/src/cmd/acme/text.c b/src/cmd/acme/text.c
index 7634d92..72b29c2 100644
--- a/src/cmd/acme/text.c
+++ b/src/cmd/acme/text.c
@@ -653,6 +653,35 @@ textcomplete(Text *t)
  return rp;
 }

+void
+xtextscroll(Text *t, int n)
+{
+ uint q0;
+
+
+ if(n == 0)
+ return;
+
+ if(t->what == Tag){
+ if(n<0)
+ texttype(t, Kscrolloneup);
+ else
+ texttype(t, Kscrollonedown);
+ return;
+ }
+
+ fprint(2, "n=%d\n", n);
+
+ if(n < 0){
+ n = -n;
+ q0 = t->org+frcharofpt(>fr, Pt(t->fr.r.min.x,
t->fr.r.min.y+n*t->fr.font->height));
+ textsetorigin(t, q0, TRUE);
+ }else{
+ q0 = textbacknl(t, t->org, n);
+ textsetorigin(t, q0, TRUE);
+ }
+}
+
 void
 texttype(Text *t, Rune r)
 {
diff --git a/src/cmd/devdraw/cocoa-screen.m b/src/cmd/devdraw/cocoa-screen.m
index 100cdd5..b83a3ff 100644
--- a/src/cmd/devdraw/cocoa-screen.m
+++ b/src/cmd/devdraw/cocoa-screen.m
@@ -1044,7 +1044,8 @@ static void
 getmouse(NSEvent *e)
 {
  float d;
- int b, m;
+ int b, m, i;
+ static int accum;

  if([WIN isKeyWindow] == 0)
  return;
@@ -1080,11 +1081,22 @@ getmouse(NSEvent *e)
 #else
  d = [e deltaY];
 #endif
+
+
+// fprint(2, "delta: %d\n", (short)d);
+
+ //fprint(2, "d: %f %d\n", d, [e hasPreciseScrollingDeltas]);
+
+ if((short)d==0)
+ return;
+
  if(d>0)
  in.mscroll = 8;
  else
  if(d<0)
  in.mscroll = 16;
+
+ in.mscroll |= ((short)d)<<1;
  break;

  case NSMouseMoved:


Re: [9fans] SHA-1 collision and venti

2017-02-26 Thread Charles Forsyth
It's curious that svn "corrupts" the repository, if that's really what they
mean, when two leaf files collide.
An index or directory colliding with a file would be more understandable.

On 26 February 2017 at 18:16, Charles Forsyth 
wrote:

>
> On 26 February 2017 at 17:25, Bakul Shah  wrote:
>
>> Venti is similarly corruptible, right? Since the checksum is over just
>> the content. If you downloaded https://shattered.i
>> o/static/shattered-1.pdf 
>>  and https://shattered.io/static/shattered-2.pdf, venti would lose the
>> contents of one.
>>
>
> Luckily, (a) they are both bigger than the block size usually configured,
> over which the hash is calculated, and (b) in case someone tries it, you've
> actually linked to the same file (-2.pdf) but under different names, so
> there won't be a collision by following your links. Hurrah!
>
> Venti detects a collision on the attempt to write the second copy if that
> differs from the earlier one stored (error "store collision"). The earlier
> copy is untouched (venti anyway is write-once per score).
> Fossil doesn't handle it well, because it turns up during archiving and
> ends up marking the archive attempt as failed, but it will try again.
> Meanwhile, you've got time to change fossil to check the venti error
> return for "score collision" and announce it, loudly, discarding the second
> one.
> Obviously if you care about something, make sure your version is in venti
> first! Chances are that collisions arise from naughty people tricking you
> later. Probably.
>


Re: [9fans] SHA-1 collision and venti

2017-02-26 Thread Charles Forsyth
On Sun, 26 Feb 2017, 18:49 Bakul Shah,  wrote:

> The links are to different files.
>

Not on Gmail at least look to see where each link points. Both are to  -2
in the message I see on Gmail. Unless it cleverly optimised the"identical"
content!


Re: [9fans] SHA-1 collision and venti

2017-02-26 Thread Charles Forsyth
On 26 February 2017 at 17:30, Jules Merit  wrote:

> there is a backdoor when a score of 4, what data produces it i have no
> idea.
>

where is that? I had a quick look but couldn't find it.


Re: [9fans] SHA-1 collision and venti

2017-02-26 Thread Bakul Shah
On Sun, 26 Feb 2017 19:57:53 GMT Charles Forsyth  
wrote:
> 
> > The links are to different files.
> >
> 
> Not on Gmail at least look to see where each link points. Both are to  -2
> in the message I see on Gmail. Unless it cleverly optimised the"identical"
> content!

I took at a look at the raw email file and you are right.
Thanks iPad + apple Mail. I can paste a URL and it gets turned
into a real link in the HTML part. But if I then edit the URL,
the link doesn't change.



Re: [9fans] SHA-1 collision and venti

2017-02-26 Thread Kim Shrier
I have had a personal project on my list of "things to do
when I have time", is to redo venti using sha256.  Does
any body see any problems with doing that?

Kim




Re: [9fans] SHA-1 collision and venti

2017-02-26 Thread Jadon Bennett
On Sun, Feb 26, 2017 at 07:57:53PM +, Charles Forsyth wrote:
> On Sun, 26 Feb 2017, 18:49 Bakul Shah,  wrote:
> 
> > The links are to different files.
> >
> 
> Not on Gmail at least look to see where each link points. Both are to  -2
> in the message I see on Gmail. Unless it cleverly optimised the"identical"
> content!

It's a multipart email; the HTML version had two of the same link, but readers 
viewing the plaintext version saw the different addresses.



Re: [9fans] SHA-1 collision and venti

2017-02-26 Thread Charles Forsyth
On 26 February 2017 at 17:25, Bakul Shah  wrote:

> Venti is similarly corruptible, right? Since the checksum is over just the
> content. If you downloaded https://shattered.io/static/shattered-1.pdf
>  and
> https://shattered.io/static/shattered-2.pdf, venti would lose the
> contents of one.
>

Luckily, (a) they are both bigger than the block size usually configured,
over which the hash is calculated, and (b) in case someone tries it, you've
actually linked to the same file (-2.pdf) but under different names, so
there won't be a collision by following your links. Hurrah!

Venti detects a collision on the attempt to write the second copy if that
differs from the earlier one stored (error "store collision"). The earlier
copy is untouched (venti anyway is write-once per score).
Fossil doesn't handle it well, because it turns up during archiving and
ends up marking the archive attempt as failed, but it will try again.
Meanwhile, you've got time to change fossil to check the venti error return
for "score collision" and announce it, loudly, discarding the second one.
Obviously if you care about something, make sure your version is in venti
first! Chances are that collisions arise from naughty people tricking you
later. Probably.


Re: [9fans] SHA-1 collision and venti

2017-02-26 Thread Bakul Shah
On Sun, 26 Feb 2017 18:25:34 GMT Charles Forsyth  
wrote:
> 
> It's curious that svn "corrupts" the repository, if that's really what they
> mean, when two leaf files collide.
> An index or directory colliding with a file would be more understandable.

The only known collision is for files. I suspect this was seen
as a "can't happen" event so may be dealing with the error was
not done right. You can read the report:
https://bugs.webkit.org/show_bug.cgi?id=168774

> > Venti detects a collision on the attempt to write the second copy if that
> > differs from the earlier one stored (error "store collision"). The earlier
> > copy is untouched (venti anyway is write-once per score).

Good to know at least it /detects/ score collisions.

The concern would be that one of two colliding files *can't*
be archived and it will be lost.  We only have one example
so it is not a big deal right now.

> > Fossil doesn't handle it well, because it turns up during archiving and
> > ends up marking the archive attempt as failed, but it will try again.
> > Meanwhile, you've got time to change fossil to check the venti error
> > return for "score collision" and announce it, loudly, discarding the second
> > one.

Hopefully the two versions can co-exist on fossil?

> > Obviously if you care about something, make sure your version is in venti
> > first! Chances are that collisions arise from naughty people tricking you
> > later. Probably.

Or may be you are doing research on collsions?!



Re: [9fans] SHA-1 collision and venti

2017-02-26 Thread Bakul Shah
The links are to different files. The pdfs look identical except for color 
background. The diff bytes are 193..320. The rest is the same so your first 8k 
byte checksum would be the same. 

> On Feb 26, 2017, at 10:16 AM, Charles Forsyth  
> wrote:
> 
> 
>> On 26 February 2017 at 17:25, Bakul Shah  wrote:
>> Venti is similarly corruptible, right? Since the checksum is over just the 
>> content. If you downloaded https://shattered.io/static/shattered-1.pdf and 
>> https://shattered.io/static/shattered-2.pdf, venti would lose the contents 
>> of one.
> 
> Luckily, (a) they are both bigger than the block size usually configured, 
> over which the hash is calculated, and (b) in case someone tries it, you've 
> actually linked to the same file (-2.pdf) but under different names, so there 
> won't be a collision by following your links. Hurrah!
> 
> Venti detects a collision on the attempt to write the second copy if that 
> differs from the earlier one stored (error "store collision"). The earlier 
> copy is untouched (venti anyway is write-once per score).
> Fossil doesn't handle it well, because it turns up during archiving and ends 
> up marking the archive attempt as failed, but it will try again.
> Meanwhile, you've got time to change fossil to check the venti error return 
> for "score collision" and announce it, loudly, discarding the second one.
> Obviously if you care about something, make sure your version is in venti 
> first! Chances are that collisions arise from naughty people tricking you 
> later. Probably.