On 5/2/12, intrigeri <intrigeri@???> 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
