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ć <krstic at solarsail.hcs.harvard.edu> | http://radian.org