#10149 NORM Not Tri: XO 1.5 olpc-update on a WP (security enabled) machine

[Zarro Boogs per Child]

#10149: XO 1.5 olpc-update on a WP (security enabled) machine
------------------------------------+---------------------------------------
           Reporter:  reuben        |       Owner:  cjb          
               Type:  defect        |      Status:  new          
           Priority:  normal        |   Milestone:  Not Triaged  
          Component:  not assigned  |     Version:  not specified
         Resolution:                |    Keywords:               
        Next_action:  never set     |    Verified:  0            
Deployment_affected:                |   Blockedby:               
           Blocking:                |  
------------------------------------+---------------------------------------

Comment(by dsd):

 Not really sure where to start here... What's the bug report?

 Yes, someone can use olpc-update to update to an image that doesn't work.
 For example if they have security enabled and it's an unsigned build, or
 if its a signed build that was signed by an untrusted party, or because
 it's an XO-1.5 image but they are running 1.0, or ..... there are a number
 of factors. olpc-update can't protect against them all.

 The question is, how are you envisioning olpc-update being used? I see
 OLPC's central olpc-update server as useless for deployments because it
 doesn't include the builds that are made by deployments. And even in the
 countries with good connectivity, running olpc-update on large scale is
 within a school is impractical for bandwidth reasons. Thirdly, it looks
 like you're thinking about children going to a root shell and typing in a
 command to perform the update -- unrealistic.

 The way I've assisted local teams to implement olpc-update in Paraguay and
 Nepal is as follows: olpc-update is left untouched and never executed by a
 human. OATS infrastructure is deployed (only the 'update' functionality is
 necessary). In the XO image, the OATS server is configured appropriately.
 Under this design, the OATS server tells the XO where the new image is
 (i.e. on local infrastructure controlled by the local team) and olpc-
 update is invoked automatically, in the background. It's then up to the
 local team to make sure they only push working images (with correct
 signatures and all that). And then from the central offices, a deployment
 can update all the laptops in a deployment without even touching a single
 XO.

-- 
Ticket URL: <http://dev.laptop.org/ticket/10149#comment:1>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system