Re: identifying which builds are signed
On Fri, Aug 01, 2008 at 12:49:31AM -0400, Mikus Grinbergs wrote: I have a general question. I'm going to be helping some Ship.2 G1G1 users (without developer keys) to perform off-line-upgrades of their systems. Currently I have to data mine through the wiki to verify which builds are signed (and can be applied from an USB stick). Things in http://download.laptop.org/xo-1/os/official/ http://download.laptop.org/xo-1/os/candidate/ can be installed on locked machines. When we sign candidates or make candidates official, we send announcements and publish the signed build in the appropriate directory. Thank you for the information. I'm concluding from your answer that there is _no_ way to tell, by examining the 'binary' of the build (e.g., os___.ucb), whether that build is signed or not. NAND-reflash-lock signatures are external to the build and are contained in the attached fs.zip. Boot-lock signatures on the kernel, initramfs, and firmware are contained in 'actos.zip', 'actrd.zip', 'runos.zip', and 'runrd.zip', on the installed filesystem. SPI-reflash-lock signatures are contained in the 'bootfw.zip'. olpc-update is presently only runnable on machines which have already passed the boot-lock; therefore its operation does not require any additional signatures. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: identifying which builds are signed
olpc-update is presently only runnable on machines which have already passed the boot-lock; therefore its operation does not require any additional signatures. Thank you. Now it makes sense to me -- a wrongdoer can insert a device and try booting it (e.g., the four-game-button press) -- so *what* he is trying to load needs to be verified for authenticity. Whereas the 'olpc-update' user already has a running system, and root privilege, so he is allowed to load. Michael, thank you for this explanation (and for describing where the signatures are contained). This is *much* clearer than the wiki, which gives cookbook explanations but does not say how come. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: identifying which builds are signed
On Thu, Jul 31, 2008 at 09:01:24AM -0400, Mikus Grinbergs wrote: You wrote, regarding nominated 8.2 builds: In a few weeks, once we're more confident in the sustainability and security of the build, then we'll publish an official candidate build with cryptographic signatures that mark it as suitable for mass installation. I have a general question. I'm going to be helping some Ship.2 G1G1 users (without developer keys) to perform off-line-upgrades of their systems. Currently I have to data mine through the wiki to verify which builds are signed (and can be applied from an USB stick). Things in http://download.laptop.org/xo-1/os/official/ http://download.laptop.org/xo-1/os/candidate/ can be installed on locked machines. When we sign candidates or make candidates official, we send announcements and publish the signed build in the appropriate directory. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: identifying which builds are signed
I have a general question. I'm going to be helping some Ship.2 G1G1 users (without developer keys) to perform off-line-upgrades of their systems. Currently I have to data mine through the wiki to verify which builds are signed (and can be applied from an USB stick). Things in http://download.laptop.org/xo-1/os/official/ http://download.laptop.org/xo-1/os/candidate/ can be installed on locked machines. When we sign candidates or make candidates official, we send announcements and publish the signed build in the appropriate directory. Thank you for the information. I'm concluding from your answer that there is _no_ way to tell, by examining the 'binary' of the build (e.g., os___.ucb), whether that build is signed or not. My interpretation of the wiki is that the 'fs.zip' file from the signed build is needed only when one is doing a clean install which wipes out the ENTIRE NAND. If one wants to preserve /home/olpc on a secured machine, one can instead use 'olpc-update' to upgrade to the new build -- and the description of 'olpc-update' says NOTHING about any 'fs.zip' file needing to be input. Thanks, mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
