Re: Can't load image 466 on my B1 machine

[Morgan Collett]

On 6/29/07, Ted Kaehler <[EMAIL PROTECTED]> wrote:
> Evaluating:  copy-nand [... a path etc]
> Can't open CRC file
>
> I tried typing
> copy-nand disk:\boot\nand466.img

Hi Ted,

Get the .crc file from where you got the .img:
http://olpc.download.redhat.com/olpc/streams/development/build466/devel_jffs2/

Rename it to nand466.crc and put it in boot/ with the .img.

Regards
Morgan
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Early boot, activation, upgrades

[Jonathan Herzog]

Now that I've looked through the code for LTC SHA-512, I'm pretty  
sure that I can examine LTC SHA-256 in a day or two. Is there an  
imminent deadline I should know about?


As for the 256-bit curve: yes, it will trigger unaudited code paths,  
but that's because I haven't yet audited every function used by the  
ECC package. ECC uses a lot of math, for example, and I haven't yet  
looked at each mathematical function yet. However, I can say that the  
256-bit curve defined in LTC matches the NIST recommendation, and  
that the unaudited code paths triggered by that curve will be in the  
underlying math functions, not LTC itself.




--
Jonathan Herzog
Cryptographic consulting
[EMAIL PROTECTED]
www.jonathanherzog.com


On Jul 10, 2007, at 1:14 PM, Ivan Krstić wrote:



Jon, do you think you would be able to audit the LTC SHA-256 code  
reasonably quickly, and do you have qualms about the NIST 256-bit  
ECC curve triggering unaudited code paths? I'm not familiar with  
that code.


--
Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org



___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Testing] RC2 and New bugs

[Zack Cerza]

Is this the same update feature as "Manual XO updates, don't lose user 
data" from http://dev.laptop.org/roadmap ? If so, maybe it should be 
removed from there.

Zack

Kim Quirk wrote:
> Scott,
> Activation we are still counting on... but we believe the update feature 
> you are working on is NOT in Trial-2. The testing we'll do with 100 
> laptops, etc. for updates is for next release (which we'll probably call 
> Trial-3, btw).
> 
> So let's talk about this and make sure that you aren't putting code in 
> the Trial-2 repository that we really don't want in there for now.
> 
> Thanks,
> Kim
> 
> 
> On 7/10/07, *C. Scott Ananian* <[EMAIL PROTECTED] 
> > wrote:
> 
> On 7/10/07, Kim Quirk <[EMAIL PROTECTED] > 
> wrote:
>  > We are 2 weeks past feature freeze. If you are working on a
> feature that you
>  > think is supposed to go into Trial-2, please talk to Jim or me
> asap. We
>  > probably need to push it out. In order to stabilize this build,
> we can't
>  > check in any new code, without a good, detailed discussion.
> Trial-2 is in
>  > 'bug fix' mode now.
> 
> Activation and upgrades aren't in the current builds yet.  Activation
> should be minimally-invasive (there's a separate initrd that we boot
> into if the machine isn't yet activated), but upgrades may need to
> move stuff around in the filesystem -- the current design pushes the
> filesystem root from / to /a (or /b) to allow recovery to a backup
> system after the upgrade.
> --scott
> 
> --
>  ( http://cscott.net/ )
> 
> 
> 
> 
> 
> ___
> Testing mailing list
> [EMAIL PROTECTED]
> http://lists.laptop.org/listinfo/testing

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Fwd: csound and glade / pygtk

[James Bergstra]

You're right that there are many good ways to make a GUI app around csound. In
TamTam, we are using csound as a sound rendering library, within a pthread that
writes directly to ALSA.  These things are controlled by a C++ python module
that we import into TamTam.

Without a clear idea of the approach you've taken, or the problems you are
facing, I venture that the following tip:

If you are using multiple threads of python code, you should be aware of the
global interpeter lock (often called GIL).  To prevent gtk from hogging the GIL
while there are no events to handle, you might want to explore the functions
threads_init(), threads_enter(), and threads_leave() in gdk.

On Fri, Jun 29, 2007 at 12:02:17PM -0400, Jean Piché wrote:
> 
> 
> Begin forwarded message:
> 
> 
> From: "dietmar offenhuber" <[EMAIL PROTECTED]>
> Date: June 29, 2007 11:44:02 AM EDT (CA)
> To: ! [EMAIL PROTECTED]
> Subject: csound and glade / pygtk
> 
> hi,
> 
> i am still having some trouble building a pyGTK interface for a csound
> application - a simple one, basically just as a replacement for FLTK
> widgets, which are not supported on the laptop. i am aware that there are
> multiple approaches at the moment, including the csound server etc.
> 
> the csound event and the pygtk interface currently run on seperate 
> threads,
> but they interfere with each other - any activity in the interface causes
> csou! nd to sto r anyone has some examples of similar applications running
> on the laptop?
> 
> best,
> dietmar
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
> 
> 

-- 
http://www-etud.iro.umontreal.ca/~bergstrj

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Can't load image 466 on my B1 machine

[Ted Kaehler]

Folks,
I am trying to upgrade a B1 XO using a Mac and a memory 
stick.  I successfully upgraded to C11 and 435.
When I tried the same thing with C17 and 466, I have a 
problem.  It installed C17 firmware just fine.
Then it says

Updating OS image on NAND FLASH from build 435 to build 466

Evaluating:  copy-nand [... a path etc]
Can't open CRC file

I tried typing
copy-nand disk:\boot\nand466.img
it says
fe
ok

What does "Can't open CRC file" indicate?
How can I get 466 onto the machine?
Thanks!
Please reply to me privately, since I am not on the devel list.

--Ted.

-- 
Ted Kaehler http://www.squeakland.org/~ted/
(home) 3261 Montecito Drive, Las Vegas, NV 89120.  voice (702) 456-7930
Science is about wanting to make progress *more* than wanting to be 
the one who makes the progress.  That is why scientists share their 
results.
-- Alan Kay
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: mesh network vs broadcast/multicast question

[Frank Ch. Eigler]

Hi -

On Tue, Jun 26, 2007 at 05:30:27PM -0400, Dan Williams wrote:

> > Is it obvious that this benefit (increased aggregate bandwidth) is
> > worth the cost [...]
>
> It depends, but packing 50 normal laptops onto a single radio channel
> _today_ with infrastructure APs doesn't really work well, especially
> when they all start to talk.  

OK, but perhaps normal laptops are not accurate enough analogues to a
bunch of XOs.  Has there been much measurement of simulated or actual
XO app traffic to see just how much yak is actually going on?

> We're likely to have that many laptops in a single classroom, and
> when you get a couple classrooms next each other...

But don't you get a factor of only 3 more with the multi-channel
scheme?  Any schools with more than three adjacent classrooms
(coarsely speaking)?

Could the system switch between the multi- vs. shared-channel schemes
considering its perceived traffic intensity?  For
away-from-schoolhouse stuff (which would probably also mean
away-from-internet), let the system use a fixed channel (or, say,
wherever it detects most nearby XO's are already squatting).  Let it
try to move elsewhere only if the local traffic is too loud.

- FChE
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: mesh network vs broadcast/multicast question

[Frank Ch. Eigler]

Hi -

On Tue, Jun 26, 2007 at 04:49:40PM -0400, Dan Williams wrote:
> [...]
> > Does this mean that one needs a school server/bridge in order to talk
> > to two differently-channeled friends ?
> 
> Yes.  You must spread the XOs between channels to maximize the overall
> system bandwidth [...]

Is it obvious that this benefit (increased aggregate bandwidth) is
worth the cost (the necessity for a special bridge - possibly
hamstringing an ad-hoc mesh away from the schoolhouse)?  How
bandwidth-hungry are common XO activities anyway?

- FChE
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: mesh network vs broadcast/multicast question

[Frank Ch. Eigler]

Dan Williams <[EMAIL PROTECTED]> writes:

> [...]  We are letting users manually "search" for friends, which is
> a fairly lengthy process that involves jumping to each channel,
> searching for friends and activities using mDNS, then to the next
> channel [...]

Does this mean that one needs a school server/bridge in order to talk
to two differently-channeled friends ?

- FChE
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

RE: [linux-pm] Re: Power Mangement Interfaces

[Woodruff, Richard]

> As you know we want user configuration of enabled wakeup events (unlike
> embedded platforms where this is hardcoded). It seems that the current
> interface available for that is /sys/devices/../power/wakeup hook (when
> !ACPI).
> 
> However there are several wakeup capable devices in OLPC which do not
> have drivers, thus no platform devices:
> 
> - power button
> - lid
> 
> It seems that creating platform devices for these two just for the
> purpose of a having an interface for enabling wakeup events is overkill.
> 
> Given that, we probably want something similar to what was initially
> described in http://wiki.laptop.org/go/Power_Management_Interface ?
> 
> The downside of doing that is a non-unified interface: platform
> devices via /sys/devices/../power/wakeup and otherwise
> /sys/whatever/wakeup/source?
 
Perhaps it is over kill, but is it really very expensive for handful of 
devices?  I am curious as to others experiences here.

In hacks for embedded in the past I've sprinkled some extra device/bus 
registrations around to provide a common way to enable wake ups and idle 
states.  I don't know that it was the best way to do it, but it could be made 
to work.

A dev structure is a handy thing to have around and provides symmetry.  Having 
a sysfs entry provides for an easy way to set and test from user space.  You 
can always export the function in the kernel also to get a secondary path to 
the function.  All that seems nicer than adding ioctrls and the like per driver.

Regards,
Richard W.

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [sugar] New activities proposals due today...

[Justin Gallardo]

Jim,

I would like to extend the Watch & Listen activity to the pool of activities.

Currently, we have a very stable version that plays amazingly on the
new b3 hardware. I know there have been issues in the past, and would
like to try and conquer them again.

What will it take to get the activity into the trial?

Thanks!

Justin Gallardo

On 6/19/07, Jim Gettys <[EMAIL PROTECTED]> wrote:
> As you know, we're coming up on feature freeze on our next major set of
> Trial software.  If you are developing an activity you'd like to see
> available as part of the trial, please let us know today so we can have
> some insight into its state.
> Best regards,
>   - Jim
>
> --
> Jim Gettys
> One Laptop Per Child
>
>
> ___
> Sugar mailing list
> [EMAIL PROTECTED]
> http://lists.laptop.org/listinfo/sugar
>
>


-- 
Justin Gallardo
Open Source Lab
Watch & Listen
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: German Press

[Jörn Engel]

On Fri, 8 June 2007 22:32:21 +0200, Bert Freudenberg wrote:
> 
> But it's amazing how people can get it so wrong - like, in the Sat.1  
> news I was credited as "Prof." Bert Freudenberg of "Hasso-Plattner- 
> Institut", even though I'm positive I gave them my card which says  
> none of this. Sigh.

Sturgeon's law.  It affects the press no less than any other area.

Jörn

-- 
More computing sins are committed in the name of efficiency (without
necessarily achieving it) than for any other single reason - including
blind stupidity.
-- W. A. Wulf
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: German Press

[Jörn Engel]

On Fri, 8 June 2007 16:58:09 +0200, Bert Freudenberg wrote:
> 
> I gave a talk in Potsdam yesterday which resulted in surprisingly  
> large press coverage for OLPC. Which is good, comments were positive  
> in general. Unfortunately, not every journalist gets their quotes  
> exactly right - in a least one publication they wrote that I was the  
> only German "OLPC" developer, when in fact I said that I was the only  
> German member of the Etoys team.

That must have been the Spiegel.  The article was corrected by now. :)

Jörn

-- 
Audacity augments courage; hesitation, fear.
-- Publilius Syrus
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Using --excludedocs and --excludepath with yum

[seth vidal]

On Sun, 2007-06-03 at 23:37 -0400, Bernardo Innocenti wrote:
> Is it possible?
> 
> This would reduce the amount of postprocessing
> we need to do when building OLPC images.

Docs frequently include licenses. Are you sure you're allowed to do that
if you're redistributing the olpc image?

-sv


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Spreadsheets/ Slideshows

[Eben Eliason]

Ever since this project began, I've had this idea in my head regarding
what a "slideshow" might mean on the OLPC machine.  I'd really like to
see an activity called "Collage" which is something like a modern
descendent of Hypercard.  It should take the idea of embedding media
further, of course allowing images, sounds, video and text, but
perhaps also supporting live logo turtles, live editable text boxes
and other interactive forms.  Ideally, there would be an interface
which made it pluggable so that any activity could embed its formats
and provide hooks for interacting with it.

Bringing it all together, it should support a basic logo-like
scripting language.  This could allow simple actions like "next page",
but could also be allowed to pull text from the live text boxes via
some identifiers, animate the embedded objects, track some basic mouse
and keyboard events, and interact with hooks provided by the plugins.

A child could create a single page, or a simple slideshow, but by
taking full advantage of the nature of the scripting which pulls
things together, they can create non-linear books, interactive
animations, science reports with embedded interactive experiments,
games, and more.

As fun as this would be for kids, I also see this as being a fantastic
format for teachers to create lesson plans in:  provide some
instructions with text and images, embed a video about the topic,
script up a little physics simulation that the kids can experiment
with, embed an abiword table widget which automatically records the
results of the experiment, and place some questions with textboxes at
the end so the kids can answer them and then turn in their "lab."
Heck, you could even automatically check the answers when they are
done, or interactively assist them when they answer incorrectly,
nudging them along or referencing the results table again.

- Eben


On 6/2/07, Rebecca Gettys <[EMAIL PROTECTED]> wrote:
> Hi All,
> I think that sideshows CAN be very sueful in the class room, and they
> have actually taught be to pay attention to detail. You need notes to do
> anything really, and they do have their applications with other
> students. Just a thought.
> ~Rebecca
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: TamTam roundup.

[Barry Vercoe]

Jean
On CPU usage at least, you'll double your throughput when you get to use the 
new 
fixed-point option in Csound.  Many other shortcuts forthcoming too.
-- barry

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Trac #1049] Rotating in reverse and/or better feedback for the rotate button

[Eben Eliason]

> I think #2 is the simplest...

I agree, actually.  I have two further comments on #2.

First, the only reason I considered 3 a better option is because I
wasn't sure which vertical orientation would be preferred.  It may be
easier for kids to operate the controls with their dominant hand.  Or
perhaps, to the contrary, they would prefer to hold it with the handle
in their dominant hand. I wasn't sure if we should remove that choice
or not.  As a plus, it would make the controls orientation
consistent...

Second, I actually think that #3 is a good idea even if we choose to
make it a toggle.  The feedback is more immediate that way, and it
would allow a short delay period in which to press the button again,
essentially canceling the rotation request.

- Eben


> On 5/9/07, Zarro Boogs per Child <[EMAIL PROTECTED]> wrote:
> > #1049: Rotating in reverse and/or better feedback for the rotate button
> > -+--
> >   Reporter:  pengo   |   Owner:  jg
> >   Type:  defect  |  Status:  new
> >   Priority:  normal  |   Milestone:  BTest-4
> >  Component:  sugar   | Version:
> > Resolution:  |Keywords:
> > -+--
> > Changes (by Eben):
> >
> >   * summary:  Holding the rotate button => Rotating in reverse and/or
> >   better feedback for the rotate button
> >
> > Comment:
> >
> >  Hmm, good question.  I see a few possible approaches to this issue, and
> >  I'm not sure what will work best.
> >
> >
> >  1) Hold the rotate button for an extended time (1 sec?) to rotate backward
> >  [[BR]][[BR]]
> >  2) Support only 1 vertical and one horizontal orientation, so the button
> >  is actually just a toggle, eliminating the problem altogether
> >  [[BR]][[BR]]
> >  3) Implement a delay on the actual rotate action, but show a small,
> >  centered onscreen graphic immediately when the button is pressed
> >  indicating the direction up will take once the rotation occurs.  Then,
> >  pressing the button 3 times quickly would have the effect of rotating the
> >  indicator graphic 270CCW (-90CW), and after short delay a single rotation
> >  event can occur.
> >
> >
> >  I think the latter two are the better options, since they are clearly
> >  discoverable.  The last may actually be the best, since it provides more
> >  immediate feedback about the button's function.  Thoughts?
> >
> > --
> > Ticket URL: 
> > One Laptop Per Child 
> >
>
>
> --
> Walter Bender
> One Laptop per Child
> http://laptop.org
> ___
> Devel mailing list
> [EMAIL PROTECTED]
> http://mailman.laptop.org/mailman/listinfo/devel
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: System update spec proposal

[Wayne Davison]

On Wed, Jun 27, 2007 at 11:37:07AM +1000, [EMAIL PROTECTED] wrote:
> That "100 bytes per file" is very approximate. It also increases quite
> a lot if you use --delete and also increases if you use --hard-links.

The increase for --delete got greatly improved a while back (the delete
scan used to at least double the size of the file list, but now only
requires the memory size of the largest directory in the delete scan).

Rsync doesn't attempt to be a really low-memory application for small
transfers, but it does try to keep the per-file memory use as low as it
can.  One sad thing is that the forking of the second rsync process on
the receiving side no longer shares the file-list memory between the two
processes on 2.6.x versions of Linux (due to a move away from copy-on-
write memory allocation in forks), so that doubles the size of the file-
list on the receiving side.

> Alternatively, talk to Wayne Davison about rsync 3.0. One of the core
> things that brings is lower memory usage (essentially automating the
> breakup into directory trees that I mentioned above).

I wouldn't recommend deploying rsync 3 widely just yet.  I'm going to be
working on finalizing the release in the near future, but there is still
a chance that protocol 30 (which is new for this release) may still need
to be changed a bit before it is released.  The program is stable enough
that I use it for all my own rsync copying, but I also ensure that my
installed versions get updated for new releases.

..wayne..
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Eliminating static binaries (Was: Unwanted RPM dependencies)

[David Zeuthen]

On Mon, 2007-06-04 at 22:52 -0400, Bernardo Innocenti wrote:
> The contents of jffs2 and ext3 images should be identical
> to simplify distribution.

Wasn't a goal when I wrote the OLPC build system (it was, however, a
goal to create four separate images aka streams (devel/non-devel
msdos-partitioned-ext3-for-usb-sticks/jffs2). I appreciate that goals
change however, I'm not active in the OLPC project anymore.

> And by the way, the kernel depends on mkinitrd so we can't remove
> it without breaking RPM deps.  

I was proposing to create an empty dummy RPM package with

 Provides: mkinitrd

and also one symlink /sbin/mkinitrd -> /bin/true. If I were to do the
OLPC build system all over again, I'd have one such RPM for dropping
deps that way. Not super nice, but effective.

> > Probably cryptsetup doesn't need to be linked statically anymore; Peter
> > Jones would know.
> 
> Good.  But, why do we need *any* static binary in the first
> place?  

Historical reasons, don't ask.

> Also, I dismiss the argument that today's computers have
> huge hard drives anyway so let's waste them.  Bigger hard
> drives are meant to hold more data, not the same amount of
> data stored in inefficient formats.  

Take it easy, it's not like I'm disagreeing with you.

> Some binaries we may wont to relink dynamically:
> 
>  - /sbin/e2fsck (dynamic on debian)
>  - /sbin/dmsetup.static (dynamic on debian)
>  - /sbin/insmod.static (dynamic on debian)
>  - /sbin/ldconfig (yes, even this one!)

Yes, in 99.999% of all cases (that's five nines for you), it's
absolutely unnecessary to have any static binaries at all in the default
Fedora install. If you had read the archives of fedora-devel-list (which
you Cc'ed yourself) you would have found

 - a huge discussion on "static linking considered harmful"; started
   by Ulrich Drepper. Some people have even more extreme points of
   of view than you. Here's a paper by Ulrich

http://people.redhat.com/drepper/no_static_linking.html

 - that early user space in Fedora is increasingly moving to
   dynamic linking; that's a good thing; even better if people
   remember to kill statically linked binaries :-)

   David


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Unwanted RPM dependencies

[David Zeuthen]

On Mon, 2007-06-04 at 03:37 -0400, Bernardo Innocenti wrote:
>  - mkinitrd depends on lvm2 and dmraid.  Both could easily
>be made optional.

You most probably don't need mkinitrd on OLPC as the kernel got all the
drivers built-in and IIRC OLPC don't even use the initrd (when I was
working on it, it didn't). So you could have some OLPC specific package
that provides mkinitrd and symlinks /sbin/mkinitrd -> /bin/true or
something.

>  - hal depends on cryptsetup-luks (containing bulky 1.2MB
>static binary in /sbin)

Probably cryptsetup doesn't need to be linked statically anymore; Peter
Jones would know. Either way, if you don't expose LUKS encrypted stuff
in the UI I guess you can just drop the cryptsetup dep from hal since it
will gracefully recover and just throw and error if Crypto.Setup() is
called.

  David


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Presentacion UTUTO XS 2007 y UTUTO InteractiveTV

[Pablo Manuel Rizzo]

Es probable que muchos de ustedes ya estén al tanto, pero para aquellos 
que no se hayan enterado, los invito a vernir el Lunes que viene a la 
presentación de UTUTO XS 2007. Si pueden también difundan la invitación 
a quienes les parezca oportuno...

Muchas gracias!

__

*El Centro Cultural de la Cooperación Floreal Gorini presentará 2 
proyectos desarrollados por el equipo de personas que componen el 
Proyecto UTUTO*. En esta oportunidad se presentará la version 2007 del 
sistema operativo GNU con kernel Linux llamado *UTUTO XS 2007* y el 
sistema de televisión interactiva por web, cuyo nombre es *UTUTO 
InteractiveTV*.


La presentación sera el dia *4 de Junio* del 2007, a las *18 horas* en 
la sala Solidaridad en el *Centro Cultural de la Cooperación*, *Av. 
Corrientes 1543 *(C1042AAB) Ciudad de Buenos Aires, Arg. Informes: (011) 
5077-8000.


La entrada es libre y gratuita y nos gustaría contar con su presencia.

__

Más información en:  https://www.ututo.org/www/xs2007.php


Saludos!

--
Pablo Manuel Rizzo
--
Aunque supiera que el mundo se acabará mañana,
Igual plantaría mi manzano.   -- Martin Luther King --
--


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Request hosting for project vision-screening

[Mitchell N Charity]

1. Project name : vision-screening
2. Existing website, if any : http://wiki.laptop.org/go/Vision_screening
3. One-line description : Activities for vision screening (checking eye 
health).
4. Longer description   : Vision screening is looking for children who 
should be
   : referred to an eye-care professional.
   : These are activities to support that process.
   :

5. URLs of similar projects :

6. Committer list 
  Please list the maintainer (lead developer) as the first entry. Only list 
  developers who need to be given accounts so that they can commit to your

  project's code repository, or push their own. There is no need to list
  non-committer developers.

 Username   Full name SSH2 key URLE-mail
    - --
  #1 mncharity Mitchell N Charity attached [EMAIL PROTECTED]
  #2
  #3
 ...

  If any developers don't have their SSH2 keys on the web, please attach them 
  to the application e-mail.


7. Preferred development model

  [X] Central tree. Every developer can push his changes directly to the 
  project's git tree. This is the standard model that will be familiar to 
  CVS and Subversion users, and that tends to work well for most projects.


  [ ] Maintainer-owned tree. Every developer creates his own git tree, or
  multiple git trees. He periodically asks the maintainer to look at one
  or more of these trees, and merge changes into the maintainer-owned,
  "main" tree. This is the model used by the Linux kernel, and is 
  well-suited to projects wishing to maintain a tighter control on code

  entering the main tree.

  If you choose the maintainer-owned tree model, but wish to set up some
  shared trees where all of your project's committers can commit directly, 
  as might be the case with a "discussion" tree, or a tree for an individual 
  feature, you may send us such a request by e-mail, and we will set up the 
  tree for you.


8. Set up a project mailing list:

  [ ] Yes, named after our project name
  [ ] Yes, named __
  [X] No

  When your project is just getting off the ground, we suggest you eschew
  a separate mailing list and instead keep discussion about your project
  on the main OLPC development list. This will give you more input and 
  potentially attract more developers to your project; when the volume of 
  messages related to your project reaches some critical mass, we can 
  trivially create a separate mailing list for you.


  If you need multiple lists, let us know. We discourage having many 
  mailing lists for smaller projects, as this tends to

  stunt the growth of your project community. You can always add more lists
  later.

9. Commit notifications

  [ ] Notification of commits to the main tree should be e-mailed to the list
  we chose to create above
  [ ] A separate mailing list, -git, should be created for commit
  notifications
  [X] No commit notifications, please

10. Shell accounts

  As a general rule, we don't provide shell accounts to developers unless 
  there's a demonstrated need. If you have one, please explain here, and

  list the usernames of the committers above needing shell access.

  Apparently one needs shell access to upload distribution .xo files.  mncharity

11. Notes/comments:
  The first Activity in this project, a visual acuity test, has existing code,
  and is targeted at TRIAL-2.


ssh-rsa 
B3NzaC1yc2EBIwAAAQEA2/EgmZTwcrqGP/ZeRhIBTkjxbK/eiwJdhuBhQrAgQhaaW1+Ib1m/XWVU1rXpfUwgLysHBKINp2K0PjXqcTHZYKSf/ySSbC60Ci9WYN4GUBNWQRkRTo8/+9omZwGbu8bd/8QZ06Dv3XQYYUmKNjYTcr++1SEBVlopyntPiYHN00vdzSrUBHrzx7WjBCdamUvetN3wnEineQxd0WzYu2nRP8rKhVJ2QE+JmWsjo9j570+oyFWvoDkq72WjsBzU9xu6PFQs15zjebYvjlnhVG8vdThZ2m66DqIDeTr5gtFQYnGnOXdntciLFMV3AvNLdnJXzyDsh5Rtb8TuPgfehyNc/Q==
 mncharity olpc git
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Early boot, activation, upgrades

[C. Scott Ananian]

Clearly we have to hash & check an unknown kernel given to us on a USB
drive (say), but is checking the authenticity of the kernel on our
flash actually buying us any security?  It's much easier to 0wn the
system by altering the root fs then by backdooring the kernel.
Protecting the root fs by extension protects the kernel images.
Unless we're actually going to do a full cryptographic authentication
of the entire FS image at every boot, the kernel checking is just
security theater.

On the other hand, if we are to boot from an external USB device, we
*definitely* need to require an initramfs.  We should authenticate the
kernel and the initramfs, and then the initramfs must authenticate the
rest of the filesystem before allowing boot.

I may be missing an essential threat here.  Discussion wanted.
 --scott

-- 
 ( http://cscott.net/ )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Early boot, activation, upgrades

[Mitch Bradley]

Complete timings for bios_crypto on LX:

Whirlpool:  1.16 sec / MiB
SHA512:   0.42 sec / MiB
RSA verification: 0.025 sec / hash
ECC verification: 1.13 sec / hash

Combined time for verifying 1MiB firmware image is 1.16 + 0.42 + 2*0.025 
+ 2*1.13 ~= 3.9 sec.

That is 2.3 sec fixed + 1.6 sec / MiB

Assuming a 1.5 MiB kernel + 2 MiB initrd, the 4-check time would be 
about 8 seconds.

If we used SHA512+RSA only, the kernel+initrd time would be about 1.5 
seconds.

For a 1.5 MiB kernel with no ramdisk, the SHA512+RSA time would be about 
0.7 seconds.

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Early boot, activation, upgrades

[C. Scott Ananian]

On 7/10/07, C. Scott Ananian <[EMAIL PROTECTED]> wrote:
> The AES encryption on the Geode is spec'ed at 40MiB/sec.  Using a
> fixed key converts AES into a hash function which is over 50x faster
> than what we've got.

I take this back, partially: the Geode AES is geared towards bulk
encryption with a fixed key.  Although my copy of Applied Crypto is at
home, hash-using-block cipher algorithms rekey often (see
http://en.wikipedia.org/wiki/Hash_functions_based_on_block_ciphers and
its footnote 1).  I couldn't immediately find cycle breakdowns for
rekeying on the Geode, but it's reasonable to assume that we can't
quite hash at 40MiB/s.  However, the 50x factor gives us plenty of
room to play with, and the Geode AES interface lets us pipeline the
two halves of an MDC-2 implementation (
http://eprint.iacr.org/2006/294.pdf ).  It may be of academic interest
to implement and benchmark AES-128/MDC-2 now that I've got an XO, but
from what I'm hearing our hash algorithms are already pretty much set
in stone.
 --scott

-- 
 ( http://cscott.net/ )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: OpenID - status?

[Martin Langhoff]

On 7/11/07, Ivan Krstić <[EMAIL PROTECTED]> wrote:
> On Jul 10, 2007, at 9:37 AM, C. Scott Ananian wrote:
> > As I understand the BitFrost specification, OpenID is only used to
> > extend the local authentication mechanisms (XO-to-school server) to
> > the outside world (Google backups, etc).
> > The actual authentication of XOs and users is done by us outside
> > OpenID.  So the DNS weakness and MiM attacks are only valid outside
> > our scope.
>
> That's correct. OpenID, in a vacuum, is a fine mechanism. It's the
> way people are doing authentication to their OpenID IDPs on the wider
> Internet that's problematic and dangerous; we can generally avoid the
> issues entirely by authenticating transparently to the school server
> in the background.

HI Ivan,

in that scope, are there any plans as to where the IDP resides? School
server? Laptop?

If it is the school server, it'd be reasonable to teach moodle to be
an IDP. If not, I won't hurry on that side. (Though that still
leavesus with the issue of authenticating the user transparently to
moodle on the school server in the first place)

cheers,


m
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Early boot, activation, upgrades

[C. Scott Ananian]

On 7/10/07, C. Scott Ananian <[EMAIL PROTECTED]> wrote:
> The AES encryption on the Geode is spec'ed at 40MiB/sec.  Using a
> fixed key converts AES into a hash function which is over 50x faster
> than what we've got.

For reference, that would be p512 of
http://www.amd.com/files/connectivitysolutions/geode/geode_lx/33234E_LX_databook.pdf
and chapter 18 of Applied Cryptography, "ONE-WAY HASH FUNCTIONS USING
SYMMETRIC BLOCK ALGORITHMS".

As a stopgap, using only SHA-512 (and leaving off the whirlpool hash)
will more than double our authentication speed.
 --scott

-- 
 ( http://cscott.net/ )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Early boot, activation, upgrades

[Ivan Krstić]

On Jul 10, 2007, at 4:09 PM, Mitch Bradley wrote:
> Such code is welcome in principle, but in practice, I don't really  
> have time to reintegrate different code for the near term deliveries.

Yeah, it's not a near-term solution at all. If we do anything, a  
changeover to faster primitives that doesn't break the OFW  
integration in any way is the only thing I consider viable.

--
Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Early boot, activation, upgrades

[Ivan Krstić]

On Jul 10, 2007, at 3:52 PM, Mitch Bradley wrote:
> Whirlpool takes 1.16 sec/MiB.  SHA512 takes 0.42 sec/MiB  (on a preB3,
> i.e. an LX CPU).

Maybe we have to change the primitives we're using. These timings are  
entirely acceptable for BIOS updates, but not quite enjoyable for  
every boot (which we didn't have in mind when we were rolling the  
crypto). We could come down to shorter RSA and ECC, and SHA-256 and  
256-bit truncated Whirlpool. Unfortunately, our crypto audit has been  
performed on the current set of primitives.

Jon, do you think you would be able to audit the LTC SHA-256 code  
reasonably quickly, and do you have qualms about the NIST 256-bit ECC  
curve triggering unaudited code paths? I'm not familiar with that code.

--
Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Early boot, activation, upgrades

[C. Scott Ananian]

It's probably too late now, but..

The AES encryption on the Geode is spec'ed at 40MiB/sec.  Using a
fixed key converts AES into a hash function which is over 50x faster
than what we've got.
 --scott

-- 
 ( http://cscott.net/ )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Early boot, activation, upgrades

[Mitch Bradley]

Ivan Krstić wrote:
> On Jul 10, 2007, at 4:00 PM, NoiseEHC wrote:
>   
>> There is an MMX WHIRLPOOL version in cripto++. Are you using that?
>> 
>
> We had to optimize for code size, and the only suitably licensed  
> library we could find that would let us squeeze all four primitives  
> into a ~60K package was LTC. The git tree is here:
>
>  git://dev.laptop.org/bios-crypto
>
> Code from other libraries that has an equal or smaller compiled  
> footprint and is faster is certainly welcome.
>   

Such code is welcome in principle, but in practice, I don't really have 
time to reintegrate different code for the near term deliveries.

> --
> Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org
>
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>   

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Early boot, activation, upgrades

[Ivan Krstić]

On Jul 10, 2007, at 4:00 PM, NoiseEHC wrote:
> There is an MMX WHIRLPOOL version in cripto++. Are you using that?

We had to optimize for code size, and the only suitably licensed  
library we could find that would let us squeeze all four primitives  
into a ~60K package was LTC. The git tree is here:

 git://dev.laptop.org/bios-crypto

Code from other libraries that has an equal or smaller compiled  
footprint and is faster is certainly welcome.

--
Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Early boot, activation, upgrades

[NoiseEHC]

There is an MMX WHIRLPOOL version in cripto++. Are you using that?

Mitch Bradley wrote:
> Whirlpool takes 1.16 sec/MiB.  SHA512 takes 0.42 sec/MiB  (on a preB3, 
> i.e. an LX CPU).
>
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
>
>   
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Early boot, activation, upgrades

[Mitch Bradley]

Whirlpool takes 1.16 sec/MiB.  SHA512 takes 0.42 sec/MiB  (on a preB3, 
i.e. an LX CPU).

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Teleconference information for software status meeting (today, 21:00 EDT Boston)

[Jim Gettys]

Please take some time and go through trac and comment/close bugs
that are done. You can easily use the query page in trac to see what
open issues you have.  http://dev.laptop.org has a number of common
useful queries.

Please send any agenda items.

DIAL IN:
  From  the United States: 866-213-2185 
  From Outside the United States:  1-609-454-9914

access code: 8069698 

problems? Call customer care 
800-526-2655 or 205-206-2301

http://www.timeanddate.com/worldclock/fixedtime.html?month=7&day=10&year=2007&hour=21&min=0&sec=0&p1=43

Status
backup/restore
Power management testing - need a full court press on verification.
Blockers for Trial-2
http://dev.laptop.org/query?status=new&status=assigned&status=reopened&priority=blocker&milestone=Trial-2&order=priority
Power management
http://dev.laptop.org/query?status=new&status=assigned&status=reopened&keywords=power&order=priority
School server status

Priorities
  * Power design verification
  * Get the base system and firmware together for Trial-2
  * Getting the server ready for trial
server - wad
Backup needed for laptops to servers urgently
  * Power management & blockers


Old Action items:
AI: Wad to mail Kim with links to latest school server progress. (?)


-- 
Jim Gettys
One Laptop Per Child

-- 
Jim Gettys
One Laptop Per Child


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Early boot, activation, upgrades

[Mitch Bradley]

C. Scott Ananian wrote:
> On 7/10/07, Mitch Bradley <[EMAIL PROTECTED]> wrote:
>> In particular, the current code does:
>> Hashes file data with whirlpool
>> Hashes file data with SHA-512
>> Verifies RSA signature against whirlpool hash
>> Verifies RSA signature against SHA-512 hash
>> Verifies ECC signature against whirlpool hash
>> Verifies ECC signature against SHA-512 hash
>
> Well, the four signature validation checks are independent of the size
> of the file data.  I think the original concern was whether the
> activation initramfs was going to bloat the kernel enough to
> significantly slow down the hashing steps.  If that is the case, then
> dropping either whirlpool or SHA-512 would help -- or we could debloat
> the initramfs, split the initramfs signature from the kernel signature
> and only check the initramfs if it is used, speed up the whirlpool
> implementation, or speed up the SHA-512 implementation.  I don't yet
> have an XO to benchmark on -- does anyone know the rough throughput
> (MB/s) of the current whirlpool and SHA-512 implementations?
> --scott
>
I'll have to do some more work to get a breakdown, but I do have a rough 
number to use as a starting point.

Using junk data as the input and a good key file (that doesn't match the 
junk data), the combined test goes at 1.5 seconds per megabyte.  That is 
basically the two hashes plus the first verification step 
(RSA+whirlpool), since the first step will fail and it won't do the 
other three.  Regression indicates that the first verify step takes 
about 35 ms - the bulk of the time is in the hash.  I think the ECC 
verification steps must be slower, because the total time for all steps 
on good data of length 100K is 2.5 seconds.




___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Early boot, activation, upgrades

[C. Scott Ananian]

On 7/10/07, Mitch Bradley <[EMAIL PROTECTED]> wrote:
> In particular, the current code does:
> Hashes file data with whirlpool
> Hashes file data with SHA-512
> Verifies RSA signature against whirlpool hash
> Verifies RSA signature against SHA-512 hash
> Verifies ECC signature against whirlpool hash
> Verifies ECC signature against SHA-512 hash

Well, the four signature validation checks are independent of the size
of the file data.  I think the original concern was whether the
activation initramfs was going to bloat the kernel enough to
significantly slow down the hashing steps.  If that is the case, then
dropping either whirlpool or SHA-512 would help -- or we could debloat
the initramfs, split the initramfs signature from the kernel signature
and only check the initramfs if it is used, speed up the whirlpool
implementation, or speed up the SHA-512 implementation.  I don't yet
have an XO to benchmark on -- does anyone know the rough throughput
(MB/s) of the current whirlpool and SHA-512 implementations?
 --scott

-- 
 ( http://cscott.net/ )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Testing] RC2 and New bugs

[C. Scott Ananian]

On 7/10/07, Zack Cerza <[EMAIL PROTECTED]> wrote:
> Is this the same update feature as "Manual XO updates, don't lose user
> data" from http://dev.laptop.org/roadmap ? If so, maybe it should be
> removed from there.

No, updating from a USB key is a separate feature.
 --scott

-- 
 ( http://cscott.net/ )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: RC2 and New bugs

[Kim Quirk]

Scott,
Activation we are still counting on... but we believe the update feature you
are working on is NOT in Trial-2. The testing we'll do with 100 laptops,
etc. for updates is for next release (which we'll probably call Trial-3,
btw).

So let's talk about this and make sure that you aren't putting code in the
Trial-2 repository that we really don't want in there for now.

Thanks,
Kim


On 7/10/07, C. Scott Ananian <[EMAIL PROTECTED]> wrote:


On 7/10/07, Kim Quirk <[EMAIL PROTECTED]> wrote:
> We are 2 weeks past feature freeze. If you are working on a feature that
you
> think is supposed to go into Trial-2, please talk to Jim or me asap. We
> probably need to push it out. In order to stabilize this build, we can't
> check in any new code, without a good, detailed discussion. Trial-2 is
in
> 'bug fix' mode now.

Activation and upgrades aren't in the current builds yet.  Activation
should be minimally-invasive (there's a separate initrd that we boot
into if the machine isn't yet activated), but upgrades may need to
move stuff around in the filesystem -- the current design pushes the
filesystem root from / to /a (or /b) to allow recovery to a backup
system after the upgrade.
--scott

--
 ( http://cscott.net/ )

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Early boot, activation, upgrades

[Mitch Bradley]

Ivan Krstić wrote:
> On Jul 10, 2007, at 8:46 AM, C. Scott Ananian wrote:
>> Can't we just SHA1 the kernel+initrd bundle and sign the hash?  SHA1
>> should be fast enough...
>
> The hashes we have available in OFW through the LTC code are Whirlpool 
> and SHA-512. It's non-trivial to amend the list at this time. The 
> current crypto code uses a slow(ish) and paranoid combination of the 
> two hashes with two signature systems because it was designed to 
> verify BIOS updates, where maximal paranoia is justified. We will want 
> to adjust the system to drop down to a single hash algorithm and 
> signature system for the normal boot integrity verification, which 
> should make it quite a bit faster.

In particular, the current code does:

Hashes file data with whirlpool
Hashes file data with SHA-512
Verifies RSA signature against whirlpool hash
Verifies RSA signature against SHA-512 hash
Verifies ECC signature against whirlpool hash
Verifies ECC signature against SHA-512 hash

If we want to use an abbreviated test for the kernel, I will need to 
change the packaging of the crypto code so the firmware has 
finer-grained access to the piece-parts.

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: RC2 and New bugs

[C. Scott Ananian]

On 7/10/07, Kim Quirk <[EMAIL PROTECTED]> wrote:
> We are 2 weeks past feature freeze. If you are working on a feature that you
> think is supposed to go into Trial-2, please talk to Jim or me asap. We
> probably need to push it out. In order to stabilize this build, we can't
> check in any new code, without a good, detailed discussion. Trial-2 is in
> 'bug fix' mode now.

Activation and upgrades aren't in the current builds yet.  Activation
should be minimally-invasive (there's a separate initrd that we boot
into if the machine isn't yet activated), but upgrades may need to
move stuff around in the filesystem -- the current design pushes the
filesystem root from / to /a (or /b) to allow recovery to a backup
system after the upgrade.
 --scott

-- 
 ( http://cscott.net/ )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

RC2 and New bugs

[Kim Quirk]

Test group (and others),

Bugs that are found as part of testing should go into the system as
'untriaged' until we get to the end of this release.  Exceptions would be if
you wrote the bug and you know it isn't need for Trial-2; or if you have
spoken to Jim or Kim and they suggested that your bug reports should be in a
later release.

As part of our clamping down on the code changes that are going into this
stream, we are triaging all new bug reports every day to make sure we
want/need to fix something in this release or whether it makes sense to move
it out.

Also, the test group should be using build 494, which we will call RC2. It
was built last weekend and it is somewhat stable with lots of features.
Let's plan to use this build for a few days to get to some deeper level of
bugs.


Developers,

We are 2 weeks past feature freeze. If you are working on a feature that you
think is supposed to go into Trial-2, please talk to Jim or me asap. We
probably need to push it out. In order to stabilize this build, we can't
check in any new code, without a good, detailed discussion. Trial-2 is in
'bug fix' mode now.

Thanks!
Kim
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: updatinator benchmarking (Was: rsync benchmarking)

[Ivan Krstić]

On Jul 10, 2007, at 11:15 AM, Alexander Larsson wrote:
> I though the whole security system was new code.

The security system doesn't get involved in updates any more than is  
necessary to verify the integrity of what was downloaded, and then  
jiggle the right symlinks. That part is irreducible complexity. How  
we get the update bits isn't.

> And anyway, you can
> verify every bit of the downloaded data once updatinator has sucked it
> down using the sha1 hashes, there is no need to trust the downloader.

It's not a matter of cryptographic trust. It's a matter of what  
happens if the downloader screws up _for any reason_ and isn't able  
to correctly fetch updates, causing the integrity checks to fail and  
leaving the machines in a state where they can't be updated.

> I'm happy your work on security is continuing, but I'm not gonna  
> let it
> block my work.

Updates are completely orthogonal to the security _work_. The update  
system needs my signoff as the security owner at OLPC, and I'm not  
giving one to new code for FRS. I made it clear that I don't mean for  
this to block your _work_ on updatinator, but I _will_ block its  
inclusion into the FRS image, a decision I'm happy to revise down the  
line.

--
Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: updatinator benchmarking (Was: rsync benchmarking)

[Alexander Larsson]

On Tue, 2007-07-10 at 10:54 -0400, Ivan Krstić wrote:
> Alex,
> 
> On Jul 10, 2007, at 10:21 AM, Alexander Larsson wrote:
> > I've been doing some more work on updatinator.
> 
> I'm happy to see this work continuing, but I want to set clear  
> expectations for FRS. I will not give security signoff for the FRS  
> update system, in my mind one of the most critical subsystems on the  
> machine, to be based on new code.

I though the whole security system was new code. And anyway, you can
verify every bit of the downloaded data once updatinator has sucked it
down using the sha1 hashes, there is no need to trust the downloader. 

I'm happy your work on security is continuing, but I'm not gonna let it
block my work.


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Early boot, activation, upgrades

[C. Scott Ananian]

On 7/10/07, Ivan Krstić <[EMAIL PROTECTED]> wrote:
> On Jul 9, 2007, at 7:08 PM, C. Scott Ananian wrote:
> > In theory, we then do some basic XO networking setup (unwritten due to
> > a lack of XO which will be soon remedied) and then invoke activation
> > if necessary (Ivan will write this part?).
>
> I'll post code for this shortly.

Please do, even in an unfinished state.  I was re-reading the BitFrost
spec, and noticed the 'activation from USB key' option -- so early
boot need to have USB/IDE modules, etc.  This should be easy to get
working, but I'd like to finish 'activation' before I start 'upgrade'.
 --scott

-- 
 ( http://cscott.net/ )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Early boot, activation, upgrades

[Ivan Krstić]

On Jul 9, 2007, at 7:08 PM, C. Scott Ananian wrote:
> In theory, we then do some basic XO networking setup (unwritten due to
> a lack of XO which will be soon remedied) and then invoke activation
> if necessary (Ivan will write this part?).

I'll post code for this shortly.

--
Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Early boot, activation, upgrades

[Ivan Krstić]

On Jul 10, 2007, at 8:46 AM, C. Scott Ananian wrote:
> Can't we just SHA1 the kernel+initrd bundle and sign the hash?  SHA1
> should be fast enough...

The hashes we have available in OFW through the LTC code are  
Whirlpool and SHA-512. It's non-trivial to amend the list at this  
time. The current crypto code uses a slow(ish) and paranoid  
combination of the two hashes with two signature systems because it  
was designed to verify BIOS updates, where maximal paranoia is  
justified. We will want to adjust the system to drop down to a single  
hash algorithm and signature system for the normal boot integrity  
verification, which should make it quite a bit faster.

--
Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: updatinator benchmarking (Was: rsync benchmarking)

[Ivan Krstić]

Alex,

On Jul 10, 2007, at 10:21 AM, Alexander Larsson wrote:
> I've been doing some more work on updatinator.

I'm happy to see this work continuing, but I want to set clear  
expectations for FRS. I will not give security signoff for the FRS  
update system, in my mind one of the most critical subsystems on the  
machine, to be based on new code.

I want to explore other update mechanisms after we ship, and  
updatinator tops the list. I don't want to discourage your work. But  
given where we are with our software and where we need to be a couple  
of months from now, we don't have the in-house resources to give  
updatinator the kind of scrutiny that would put my professional  
paranoia at ease. We take various software risks at different places  
in our stack precisely because we're relying on the update system to  
work flawlessly. With existing, well-known tools, I can make  
reasonable guarantees about that being the case. With new ones,  
despite your obvious talent and attention to this problem, I can't.

An rsync-based solution, possibly without even Scott's wrapping  
manifest code, is the only update approach I will support for FRS.  
After that, we can revisit the issue.

Cheers,

--
Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: OpenID - status?

[Ivan Krstić]

On Jul 10, 2007, at 9:37 AM, C. Scott Ananian wrote:
> As I understand the BitFrost specification, OpenID is only used to
> extend the local authentication mechanisms (XO-to-school server) to
> the outside world (Google backups, etc).
> The actual authentication of XOs and users is done by us outside
> OpenID.  So the DNS weakness and MiM attacks are only valid outside
> our scope.

That's correct. OpenID, in a vacuum, is a fine mechanism. It's the  
way people are doing authentication to their OpenID IDPs on the wider  
Internet that's problematic and dangerous; we can generally avoid the  
issues entirely by authenticating transparently to the school server  
in the background.

--
Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

updatinator benchmarking (Was: rsync benchmarking)

[Alexander Larsson]

On Wed, 2007-06-27 at 16:02 -0400, C. Scott Ananian wrote:

> Anyway, here are some quick stats, for upgrades from build 464 to 465 to 466:

I've been doing some more work on updatinator. Now it stores the
"release" info as a simple key-value file that contains the manifest
sha1 value, and the actual manifest is just a blob like the other. This
way we automatically get gzip and bsdiff support for the manifest files
(which tend to be around 2 meg for a full olpc devel image).

Here are some stats using bsdiffs and gzip. I don't have any byte
counter in the app, so i just looked at interface RX/TX stats. It counts
the full packet size instead of the tcp stream byte count, and it might
have data from other apps running on the system, but it should give a
somewhat correct maximum limit at least.

> 464-to-465:
> Full contents of tree: 429,302,610 bytes
> rsync --whole-file: sent 32,034 bytes; received 13,153,813 bytes.
> Standard rsync: sent 96,720 bytes; received 10,047,524 bytes. 9.0s
> user, 64.9s real
> Rsync-with-manifest: sent 79,192 bytes; received 9,139,515 bytes. 4.3
> user, 11.5s real.

Updatinator:
sent 596,681 bytes
recieved 7,545,281 bytes

> 465-to-466:
> Full contents of tree: 458,828,206 bytes
> rsync --whole-file: sent 21,990 bytes; received 25,826,516 bytes.
> Standard rsync: sent 141,948 bytes; received 23,981,423 bytes. 14.0s
> user, 68.5s real
> Rsync-with-manifest: sent 125,158 bytes; received 23,171,430 bytes.
> 10.4 user, 28.5s real.

Updatinator:
sent 1,263,885 bytes
recieved 20,718,744 bytes

I haven't looked into why we're sending so much data, perhaps its due to
other traffic on my box, or perhaps the http accesses are just too
chatty. But even taking that into consideration we're doing 1.2 meg less
total network traffic in the 465-466 case than the best rsync case (and
we're not doing a lot of local disk i/o).

I'm also creating an updatinator repository at 
http://olpc1.redhat.com/updatinator/
so that people can start test it, and eventually use it to easily update
their XOs.

Another interesting piece of stats here is the size of this repository.
A repository with all the ext3 and jffs2 developer images from version
400 to 450 has a blobs directory of 1.3 gigs. The estimated size for
just the tarballs of these revisions is around 12 gigs. This is a pretty
good compression ratio. This is good for the school server disk use and
means it can easily store all old releases.


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: OpenID - status?

[C. Scott Ananian]

I'm jumping in without having a full understanding of OpenID here, so
forgive me if I get some points wrong, but:

As I understand the BitFrost specification, OpenID is only used to
extend the local authentication mechanisms (XO-to-school server) to
the outside world (Google backups, etc).

See:  
http://dev.laptop.org/git.do?p=security;a=blob;hb=HEAD;f=bitfrost.txt#l1028

The actual authentication of XOs and users is done by us outside
OpenID.  So the DNS weakness and MiM attacks are only valid outside
our scope.  For example, someone can spoof Google and/or insert
themselves in between Google and the school server, and proxy the
authentication and look at all the data going past.  But the backups
are encrypted, which mitigates this problem.  They can't attack OpenID
on the mesh, because OpenID isn't used there.

It's impossible to get perfect security.  We should look at the
possible threats in the context of our uses, and perhaps the dangers
are (or can be) mitigated.  Local MiM attacks on the wireless network
may be easy (until we implement IPv6 SEND, at least), but wired MiM
attacks between (say) an IPv6 tunnel endpoint and Google will require
large amounts of resources to accomplish.
 --scott
-- 
 ( http://cscott.net/ )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Early boot, activation, upgrades

[C. Scott Ananian]

On 7/10/07, Mitch Bradley <[EMAIL PROTECTED]> wrote:
> Decompression is fast, but the signature verification is not so fast,
> especially since there are several different algorithms.

Can't we just SHA1 the kernel+initrd bundle and sign the hash?  SHA1
should be fast enough...
  --scott

-- 
 ( http://cscott.net/ )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: OpenID - status?

[Ben Laurie]

On 7/10/07, Martin Langhoff <[EMAIL PROTECTED]> wrote:
> On 7/10/07, Ben Laurie <[EMAIL PROTECTED]> wrote:
> > The blind trust in the relying party is more of a concern to me:
> > http://www.links.org/?p=187.
>
> Good point -- that's even easier than hacking the DNS. A bit of a
> spoof IDP site and done. And those "shared secrets" between the IDP
> and the user can be proxied through to the user as the IDP cannot know
> that the user is legitimate. All I've seen so far are phrases and
> images -- both look pretty, and useless.
>
> So we have
>
>  - Blind trust in the relying party
>  - DNS weaknesses -- fixed by the PKI in HTTPS -- will the laptops
> shipped to a school have loaded the school server's PKs? Or trust a
> big OLPC-signing-cert-in-the-sky?
>  - A comment in your blog mentions MITM attacks against
> Diffie-Helmann. I'm not versed enough in the matter to judge the
> actual risk here. Google led me to
> http://www.itillious.com/insight/articles/maninmiddle.html

So, D-H is trivially MitMable. AFAIK, all known defences are patented, sadly.

>
> cheers,
>
>
> martin
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: OpenID - status?

[Martin Langhoff]

On 7/10/07, Ben Laurie <[EMAIL PROTECTED]> wrote:
> The blind trust in the relying party is more of a concern to me:
> http://www.links.org/?p=187.

Good point -- that's even easier than hacking the DNS. A bit of a
spoof IDP site and done. And those "shared secrets" between the IDP
and the user can be proxied through to the user as the IDP cannot know
that the user is legitimate. All I've seen so far are phrases and
images -- both look pretty, and useless.

So we have

 - Blind trust in the relying party
 - DNS weaknesses -- fixed by the PKI in HTTPS -- will the laptops
shipped to a school have loaded the school server's PKs? Or trust a
big OLPC-signing-cert-in-the-sky?
 - A comment in your blog mentions MITM attacks against
Diffie-Helmann. I'm not versed enough in the matter to judge the
actual risk here. Google led me to
http://www.itillious.com/insight/articles/maninmiddle.html

cheers,


martin
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: OpenID - status?

[Ben Laurie]

On 7/10/07, Martin Langhoff <[EMAIL PROTECTED]> wrote:
> Hi devel, hi server-devel,
>
> I am working on Moodle's openID auth plugin. While there is an openID
> "plugin" of sorts for v1.6 I've reviewed it and it's less than
> stellar, so I'm tackling a new one.
>
> Questions:
>
>  - Are we still happy with OpenID -- is Ivan still happy with it? I've
> done a bit of review of the protocol itself, and a quick chat with
> Mark Piper here in NZ reinforced my concerns - the whole thing has
> several weak points, a notable one being its blind trust of DNS. Will
> DNS be reasonably stable/trustable in our network env?

The blind trust in the relying party is more of a concern to me:
http://www.links.org/?p=187.

>  - Moodle will initially know how to behave as a client. Do we want it
> to be an OpenID server too? I think we do but just to check where the
> thinking is at.
>
> cheers,
>
>
> martin
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: OpenID - status?

[Ivo Emanuel Gonçalves]

On 7/10/07, Martin Langhoff <[EMAIL PROTECTED]> wrote:
> a notable one being its blind trust of DNS. Will
> DNS be reasonably stable/trustable in our network env?

I believe you may work with either IPv4 and IPv6.  The use of DNS is
to make it easier for people to remember the URI's, and that makes
sense because nobody in their right mind would like to memorize a
bunch of random numbers.

> Do we want it to be an OpenID server too?
> I think we do but just to check where the
> thinking is at.

OpenID for the OLPC, IMO, should be on a central server.  Actually, a
few months ago, I suggested that Ubuntu would link a Jabber and an
OpenID account to the Linux user account, to help people and promote
those technologies.  I believe the same should happen on the XO
system.

But I'm somewhat biased, as I believe OpenID (and Jabber, although not
related at all) to be some of the most useful things to ever hit the
Internet.

Best Regards,
Ivo Emanuel Gonçalves
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

OpenID - status?

[Martin Langhoff]

Hi devel, hi server-devel,

I am working on Moodle's openID auth plugin. While there is an openID
"plugin" of sorts for v1.6 I've reviewed it and it's less than
stellar, so I'm tackling a new one.

Questions:

 - Are we still happy with OpenID -- is Ivan still happy with it? I've
done a bit of review of the protocol itself, and a quick chat with
Mark Piper here in NZ reinforced my concerns - the whole thing has
several weak points, a notable one being its blind trust of DNS. Will
DNS be reasonably stable/trustable in our network env?

 - Moodle will initially know how to behave as a client. Do we want it
to be an OpenID server too? I think we do but just to check where the
thinking is at.

cheers,


martin
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel