Re: Keys/Signature use in OSTree/Flatpak/Flathub

[Alexander Larsson <alexl redhat com>]

On fre, 2016-10-07 at 15:35 -0400, Colin Walters wrote:
> On Wed, Oct 5, 2016, at 09:46 AM, Alexander Larsson wrote:
>
> > > Oh, wait, do you mean that we would have *unsigned* summaries,
> > > and
> > > instead relying on TLS for MITM protection, and the metadata
> > > public-
> > > facing server security (rather than the signature on the
> > > summaries)
> > > for
> > > protecting the metadata? 
>
> Yes, I'm basically proposing we should back away from summary GPG
> signatures,
> and only sign commits.  Again, proposed architecture:
>
>  - Centralized metadata server with cert-pinned TLS
>    Clients can use contenturl= to download static delta payloads
>    and individual archive objects
>  - GPG signed commits
>
> In this instance, compromising the metadata server does give
> one the ability to deny updates, or possibly "sidegrade" users
> to different trees signed with the same key, etc.
>
> But while obviously not great, those attacks are *noticeable*
> and don't (intrinsically) give the attacker to e.g. execute arbitrary
> code.

Ok. This gets rid of the need to sign the summary which is likely to
happen on the "near-public-facing" server, which helps a lot. Lets
start from this.

Does the current OSTree code actually support TLS pinning?

Any build that is automatic (e.g. a nightly build), by necessity has to
have the private key unencrypted somewhere, which greatly increases the
risk of it being exposed. Such a build can thus not really be combined
with a "stable" release in the same repo. This is the reason why gnome
has two repos, one for releases and one for nightly builds. 

This is a bit painful though. For instance in the Flathub design we'd
really like to have a "one-repo-per-app" model. Having a way to use the
repo key to sign a trust delagation statement like "The key <id> is
allowed to sign the commit for branch 'nightly-build'" would severely
limit the risk if the stable and nightly-build branches were in the
same repository.

Another example is the flathub app store. In a successful case this
would be a single repository that had hundreds of apps, one branch per
app. This will be getting a lot of updates, as at least one of these
apps probably has an update every day. With a single key having to sign
each of these we'll be forced to have someone with very high security
clearance (i.e. access to the single key that gives random-code-
execution for all apps) to daily do this stupid signature chore.

If we could use the main key to delegate each branch/app (or a subset
of apps) we could allow the maintainer of each individual app to sign
it, and we would only have to bring out the super-important key when
e.g. adding/renaming apps or changing app ownership. 

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl redhat com            alexander larsson gmail com 
He's an oversexed Amish househusband living undercover at Ringling Bros. 
Circus. She's a vivacious hypochondriac magician's assistant fleeing from 
a Satanic cult. They fight crime!