#9506 NORM 1.5-F11: Activity updater does not work

[Zarro Boogs per Child]

#9506: Activity updater does not work
------------------------------------+---------------------------------------
           Reporter:  sayamindu     |       Owner:               
               Type:  defect        |      Status:  new          
           Priority:  normal        |   Milestone:  1.5-F11      
          Component:  not assigned  |     Version:  not specified
         Resolution:                |    Keywords:               
        Next_action:  never set     |    Verified:  0            
Deployment_affected:                |   Blockedby:               
           Blocking:                |  
------------------------------------+---------------------------------------

Comment(by dfarning):

 One thing I would recommend would be be adding a hash checker.

 When we wrote the updater the the bundles were served directly from
 a.sl.o.

 Now updating is a two part process. 1. Ping aslo for update inforamation.
 2. Ping mirror system for .xo bundle.

 step 1 invovles the updater sending a url such as
 http://activities.sugarlabs.org/services/update.php?id=org.laptop.WebActivity&appVersion=0.82
 to also.

 aslo responds with

 -------------
 <RDF:RDF>
 −
 <RDF:Description about="urn:mozilla:extension:org.laptop.WebActivity">
 −
 <em:updates>
 −
 <RDF:Seq>
 <RDF:li resource="urn:mozilla:extension:org.laptop.WebActivity:102"/>
 </RDF:Seq>
 </em:updates>
 </RDF:Description>
 −
 <RDF:Description about="urn:mozilla:extension:org.laptop.WebActivity:102">
 <em:version>102</em:version>
 −
 <em:targetApplication>
 −
 <RDF:Description>
 <em:id>{3ca105e0-2280-4897-99a0-c277d1b733d2}</em:id>
 <em:minVersion>0.82</em:minVersion>
 <em:maxVersion>0.82</em:maxVersion>
 −
 <em:updateLink>
 http://download.sugarlabs.org/activities/4024/browse-102.xo
 </em:updateLink>
 <em:updateSize>333</em:updateSize>
 −
 <em:updateInfoURL>
 http://activities.sugarlabs.org/versions/updateInfo/29040/%APP_LOCALE%/
 </em:updateInfoURL>
 −
 <em:updateHash>
 sha256:d06c16a1c106dbd1a706f322d75a143d0b4e32815c22f3d95589de83e5480365
 </em:updateHash>
 </RDF:Description>
 </em:targetApplication>
 </RDF:Description>
 </RDF:RDF>
 ----------------

 step 2 involved pinging the update link returned in step 1.
 http://download.sugarlabs.org/activities/4024/browse-102.xo .

 Step 1 also returns an update hash.
 <em:updateHash>
 sha256:d06c16a1c106dbd1a706f322d75a143d0b4e32815c22f3d95589de83e5480365
 </em:updateHash>

 It would be trivial to add a hash checker to update control to verify the
 the file received via the mirror system is the same as the file the
 activites.sl.o editors approved.

 Maybe I am just being paranoid.

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