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

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,
instead relying on TLS for MITM protection, and the metadata
facing server security (rather than the signature on the
protecting the metadata? 

Yes, I'm basically proposing we should back away from summary GPG
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

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! 

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]