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

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

We are relying here on OSTree's intrinsic timestamp downgrade protection,
although that at the moment is only baked into the OstreeSysrootUpgrader
path, but it does look like it's in flatpak too:

      old_timestamp = ostree_commit_get_timestamp (old_commit);
      new_timestamp = ostree_commit_get_timestamp (new_commit);

      if (new_timestamp < old_timestamp)
        return flatpak_fail (error, "Not allowed to downgrade %s", ref);

What about keeping the single gpg key that signs everything, but just
allowing the delegation of keys?

I'm not sure I quite understand  this.

That way we would only ever need one key on the client side, but on the
server side one could chose to delegate signatures such that the main
key doesn't have to be on the system that signs the summary, or such
that a 3rd party can sign his app builds.

Practically speaking I'd expect people doing GPG in any kind of non-test
fashion to use HSMs etc.   So I'm not entirely sure what we'd be getting
with custom GPG delegation.

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