Re: deltas, history pruning vs GPG

[Colin Walters <walters verbum org>]

On Mon, Mar 16, 2015, at 09:35 AM, Giuseppe Scrivano wrote:
> 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?

Were you thinking we could just verify the commit signature, then
verify the object checksums as we're creating them?

I have two concerns:
  - We're doing a lot of data processing such as decompression, bsdiff, etc.
    before verifying content integrity.
  - Current OSTree makes it pretty trivial for a MITM to perform a DoS
    attack (just keep returning data), and I'd hoped to fix that with static deltas.

For the second concern, we could add metadata to the commit object that has size bounds
(this was previously attempted), but it's fairly ugly.

I've been thinking that the current "archive-z2" is good for a "QA continuous delivery",
and a "deltas only" repository would be good for production serving/replication.

We want to support the model where content is retrieved over an insecure channel
(e.g. plain HTTP), or in general is redistributed from the origin with opportunity
for MITM (think distribution mirrors, USB keys, etc.).  In that case it's
good for the signature to cover the transmitted data in an easy-to-validate
way before any processing is applied.

Now, what I was suggesting before is to:
 - Drop signatures on static deltas
 - Index deltas in the summary file
 - Introduce the concept of signatures on the summary file

Then we'd have the GPG signature cover SHA256 of the delta parts, and
we already have support for computing those.

> 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).

Right.  For multiple signatures I like the ability to do binary-level promotion;
your internal only build is signed by a developer key, then a QE key, then
a release key.