Re: [Tails-dev] TUF VCS repository and implementation status

On Sun, May 6, 2012 at 6:15 AM, intrigeri <intrigeri@???> wrote:
> Hi,
>
> Justin Cappos wrote (05 May 2012 02:36:54 GMT) :
>> Let me get back to you in a day or two after I've looked into the
>> issue you describe.
>
> Sure.

Okay, the short answer is that we're going to set this up in another
way soon and it'll be accessible.

The long answer is that we're moving servers soon, the bug isn't an
easy one to track down, and we are moving away from hg, so we probably
will obsolete this instead of fixing it.

>> As for projects that use TUF in production, we are being used by
>> PrimoGENI. There is a partial integration with the Seattle testbed
>> as well where we are used on their beta network. Once the
>> refactoring is done (in the next month or so) there is going to be
>> a push for Seattle use in production.
>
> Do these projects use TUF thanks to its distutils integration,
> or some other way?

PrimoGENI uses distutils, but Seattle does not.

>> quickstart was more of a demo tool than something that is used
>> widely. We've recently discussed whether to drop or refactor it.
>
> Ah. The distutils integration is not fit for our needs, that's why
> I was primarily looking at quickstart, but I'm all for you suggesting
> us better (present or future) solutions :)

Sure, this sounds good.

>> The Tails project looks very interesting. What are you looking to
>> have TUF do? Is this meant as a substitute for apt? (Note that our
>> package manager integration isn't mature and so we should discuss
>> this use case.) Are you looking to have us update other software?
>
> While Tails uses APT internally (at ISO image build time and in
> a running Live system if the user wishes), this is not how we want to
> manage system-wide incremental upgrades: the delta between two
> versions of Tails cannot be expressed purely in terms of Debian
> packages upgrades. So, no, we don't want to replace APT with TUF.
>
> 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, 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.

Is this the role you were thinking about for TUF?

Thanks,
Justin