On 5/2/12, intrigeri <intrig...@boum.org> wrote: > Hi, > > please review > https://tails.boum.org/todo/incremental_upgrades/ > > I'm particularly interested in: > > * your thoughts about the general idea and process as described > there
*Everything* which the update downloader needs to authenticate must be in the *contents* of the file whose signature is checked. Currently, an update's product name, build target, and intended update channel are not authenticated. You must include the *hashes* of other files which are part of the update in the file whose signature is checked. Verifying that other files have, at some point in the past, been signed as a component of an update is not enough to verify that those other files are part of the update you want users to install. > * questions to refine the idea, the requirements, whatever > difficulty I may have missed... Include the specific command line that you plan to use to verify the signature on an update-description document. Specify terms/phrases to be used to describe (a) the YAML file that describes the update, (b) the whole set of files included by reference into an update, and (c) any file included by reference into an update, and stick with those terms/phrases. How does gpgv react when the system clock is set to before the time at which the signature claims to have been produced? How does gpgv react when the system clock is set to before the time at which the signature-verification key claims to have been produced, or after it is set to expire? Have you read the Thandy spec and the TUF paper? > * your thoughts about "3.1.c. Updates files" -- this > work-in-progress may be slightly over-engineered, but the > potential future benefits seem big to me compared to the > added complexity. What do you think? It turned out to be under-engineered -- see above. Robert Ransom _______________________________________________ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev