Hi Justin,
Justin Cappos wrote (06 May 2012 22:27:35 GMT) :
> On Sun, May 6, 2012 at 6:15 AM, intrigeri <intrigeri@???> wrote:
>> Instead, we are evaluating TUF to poll for, download and verify
>> what we call "Incremental Upgrade Kit (IUK)" (a file that contains
>> everything needed to update from) -- an IUK is basically a tarball
>> that contains a SquashFS diff file, updated kernels, etc., that
>> will be put in place by our future updater software. In terms of
>> TUF terminology, an IUK would be a "target file". We will shortly
>> write software that generates an IUK from two Tails ISO images.
> Ah, okay. I understand what you're trying to do. TUF should be able
> to do the security side of this,
Great.
> but there may be a little bit of glue code to send information about
> the version, OS, etc. as part of the update process. Basically you
> would write the client / server code to handle this aspect and TUF
> will make everything work securely.
OK.
May you please elaborate a bit on what kind of glue code are you
thinking of, especially server-side? We need to be able to distribute
target files on a pool of untrusted, static web servers.
E.g. if we end up not using TUF, we will encode the version, OS, etc.
information in URIs to update-description files. Perhaps you could
read the current state of our not-using-TUF design work, to better
understand what kind of requirements we have:
https://tails.boum.org/todo/incremental_upgrades/
The 4.2 Implementation / Infrastructure section should be of
particular interest to you.
(Note that the security discussion is not finished yet, and might
never be, in case it looks like we can go using TUF right now.)
> Is this the role you were thinking about for TUF?
Yes, this is.
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
