Re: deltas, history pruning vs GPG

[Giuseppe Scrivano <gscrivano gnu org>]

Hi Colin,

Colin Walters <walters verbum org> writes:

> An important and large part of the OSTree problem domain boils down to getting files from A to B across the 
> Internet securely.
>
> Obviously, many software systems out there approach this, but if you add in a few characteristics:
>  - Servable over plain static HTTP
>  - Content is managed as versioned immutable snapshots
>  - Unidirectional flow
>  - Focus on executable code
>
> That eliminates things like Dropbox, rsync, git, etc. in the sense
> that while some some components of those projects might be
> useful, they're sufficiently different that implementation choices
> would vary significantly.
>
> The general class of project then falls into:
>  - Package systems
>  - Language/App updaters
>  - Basic images (ChromeOS)
>  - Complex images (Docker)
>
> This is also the same problem domain that is a focus of:
>
> http://theupdateframework.com/
>
> Which I've been looking at again.
>
> Basically, what I'm wrestling with now is whether or not deltas are GPG signed
> individually.

I've just start looking into this gpg+updater, and to get the discussion
alive again, so please forgive me in case I miss something obvious :-)

I tried to find an use-case where signing deltas would be desirable but
I couldn't imagine any.  What would be the advantage of signing the
deltas over signing the commit?

I would keep the deltas as nothing more as a "distribute new files in a
more efficient way" and not duplicate functionalities.

IMHO, signing only the commit gives a lot of flexibility, especially as
more signatures can be added later and have a sort of chain of trust
(host B gets the commit from A, with the commit signed by A.  B signs
the commit and distribute it to C, which has to trust only B).

Regards,
Giuseppe