Feature request: staged updates

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Allow ChromiumOS to fetch (download) an update image, but don't update
2. Shutdown ChromiumOS
3. Later, boot ChromiumOS

What is the expected output? What do you see instead?

Expect it to use the update image cached locally.

Instead, it download a new update image again.

What version of the product are you using? On what operating system?

ChromiumOS, most recent dev build

Please provide any additional information below.

The problem appears to be an inability to:

(1) Identify the most recent cached copy of an update image to the Omaha server 
as part of the request, rather than just the current version of the OS that's 
running on the device.

(2) Validate that the locally cached copy has the same SHA1 signature as the 
version which would be downloaded (to prevent interposition.

This could be resolved by including additional information in the request, as 
well as an additional response code indicating "use local copy" to avoid 
re-downloading (sort of like the will/won't/do/don't protocol used for IAC for 
Telnet, FTP, etc., only statically stated).

In other words, it's still necessary to validate the cryptographic signature 
with the server to make sure the image on disk doesn't have a valid signature, 
but represents an interposed image.

Original issue reported on code.google.com by tlamb...@google.com on 13 Apr 2011 at 5:29

[GoogleCodeExporter]

The official Omaha client for Windows already does this - it takes the hash 
from the server response, hashes any previously downloaded files in the package 
cache, and will not download a new file if there's a match.

This sounds like an issue with the ChromiumOS implementation of their Omaha 
client, rather than a protocol design issue.  I'll forward this issue to the AU 
guys in Chromium.

Original comment by ryanmyers@google.com on 3 May 2011 at 9:12

• Changed state: Invalid

[GoogleCodeExporter]

update_engine applies the update while downloading (rather than download and 
then apply).

update_engine tries to resume an interrupted update based on the hash of the 
available update and saved checkpoint.

It doesn't seem anything needs to be done to address this issue.

Original comment by petkov@google.com on 3 May 2011 at 9:38