On Wed, 2017-05-31 at 16:30 -0400, Colin Walters wrote:
On Sat, May 27, 2017, at 06:53 PM, Philip Withnall wrote:Let’s introduce the concept of an ‘origin’, which is a collection of related refs, all within the same trust domain.Let me echo Krzesimir on the "origin" term - we do already have that for the ostree-as-host case. How about one of: - "uremote" (unique remote) - "gu-remote" (globally unique remote) - "keybound remote"
I’d rather not use anything including ‘remote’, since that makes grepping hard. I’d also like to emphasise the fact it’s more of a location-less group of refs which have been curated by someone and are in the same trust domain. How about ‘collection’ and ‘collection ID’? (I’ll continue using ‘origin ID’ throughout this e-mail for now.)
For example, all the refs for a particular OS as provided by that OS vendor; or all the refs for flatpak apps packaged by a particular organisation; or all the personal branches produced by a specific person. An origin is tightly bound to the GPG key which is used to sign its refs, although they are not actually equivalent, because the GPG key could change in future (key rotation, etc.). So, instead of basing the origin’s identity on its key, an opaque string identifier is used instead. This could be, for example, ‘gnome-apps’, or ‘flathub’, or ‘uk.co.tecnocode’. The exact naming scheme, and how to ensure uniqueness, is up for discussion (see the section below).There's of course a very commonly used scheme to bind short globally unique, human-readable strings with cryptographic keys: the pairing of DNS and TLS used for HTTP. This type of thing is why I'm still pushing for doing "ca-pinned TLS" for metadata; so many things are instantly solved with well-understood tooling. A really good example of a problem is: https://arstechnica.com/security/2017/04/chrome-firefox-and-opera-use rs-beware-this-isnt-the-apple-com-you-want/ (Now, I'd say that adding a new flatpak source should be an unusual operation, a bit distinct from visiting a web page - and the user interface should probably reflect this) Do we expect these (i'm going to use the term "guremote") to show up in a user interface like gnome-software? It seems unavoidable.
Yes.
Hm, well I guess really we should look at Flatpakrepo files as they exist today. You mention those below. Assuming one is using an OS without flatpak repos defined already, we're basically relying on the existing TLS infra to bootstrap things.
Aside: In the Endless OS case, we would have the flatpak repos/OSTree repos defined already. Whenever a flatpakrepo file is downloaded, we are relying on a whole chain of trust decisions before it’s configured: the user picking an appropriate flatpakrepo file from a trustworthy site; the site using TLS to avoid MITM attacks; the certificate being pinned to avoid trusting the wrong site. I suspect we can do a better job with this bootstrapping process (do we currently enforce downloads over TLS? pinned certificates? verifying a signature or checksum of the flatpakrepo file against something on the website?), but this isn’t in the scope of things I’m looking at atm.
So...given the existing: ``` [Flatpak Repo] Title=Gnome Stable Runtimes Url=http://sdk.gnome.org/repo/ Homepage=https://www.gnome.org/get-involved/ Comment=The standard Gnome runtime used by most gnome apps Description=GNOME runtimes are released with each major release and contain the main GNOME platform libraries. At the moment they only receive minor bug fixing and security updates, but should be considered ABI stable and frozen. Icon=https://www.gnome.org/wp-content/themes/gnome-grass/images/gnome -logo.png GPGKey=mQENBFUUCGcB... ``` You're saying that we want the ability to change any or all of that, and so we need a new persistent value (stored in that file? Or I guess per- commit)?
I’m not quite sure where you’re going with this. As I understand things, that’s a .flatpakrepo file, which `flatpak remote-add` imports and dumps into the OSTree config file as various standard and xa.blah keys. I’m saying we need a single new key in the .flatpakrepo file format, which specifies the origin ID used by that repository, if applicable. That value would be copied into the corresponding OSTree config, or used as the remote name (depending on which scheme we use for linking the two up). It would persist there. Individual commits have nothing to do with it.
This also brings up an issue with flatpak {repo,ref} files in that
they aren't signed
with the GPG key.
Again, this is out of the scope of what I’m looking at atm. That said, what attacks would this prevent? As I understand the flatpak code, all the metadata which is in the .flatpakrepo file is re- downloaded from the OSTree repository’s summary file once the repo is added, and verified then. If the GPG key doesn’t match, that should fail. So as far as I can see, the attack here is that someone could put a false name/description/icon in a .flatpakrepo file whose URI points to a different repository. If the attacker has control of the repository’s GPG key, they can do this anyway; so they’d have to be putting false metadata on a repository they don’t control. I’m unsure as to how that could be turned into a viable attack. However, there would be little harm in bolting an inline signature onto the end of .flatpakrepo files. It would simply mean they could no longer be hand-edited. Not sure how much we care about that.
Hmm. So if we're trying to support key rotation, Alex already added the xa.gpgkeys to commits, which will cause new updates to extend the keyring. It feels like for the P2P case what we need is a way to communicate the key rotation *separately* from the apps. Then it's easier for us to ensure that all clients get notified of the latest keys.
What do you mean by ‘separately from the apps’? I’m unsure where apps fit in here. I’m pretty sure I don’t want to pull key rotation into the scope of this work as well. I’d like to ensure the P2P work allows for key rotation, but don’t want to define a key overlay and distribution network at the moment.
And once we have that done, we can simply have the repo uuid be the latest key fingerprint. In the offline computer lab case, plugging a USB stick into one with a set of "key transitions" + "commit data" would ensure that as the machines picked up the key transitions, they would then start looking for refs advertised by the new key.
Might there be situations where we want two collections of refs to have different origin IDs, but be signed by the same key? For example, if there were stable and unstable versions of an OS, where the unstable version is regularly promoted to be stable (and they’re signed with the same key to avoid having to rebuild and resign the unstable version) — but they can’t be in the same repository since one of them is password- protected or only available to a limited audience, or something? I probably should clarify that when I said ‘GPG keys are strongly bound to origin IDs’, the relation I had in mind was one-to-many: one GPG key may be bound to several origin IDs. Each origin ID has only one GPG key. Another (minor) argument against using GPG keys as the origin IDs is their length. Fingerprints are (currently) 40B, but an ID like ‘gnome- apps’ is 10B. That will add up a bit in the summary file. That said, the design I have in mind lists each origin ID exactly once in the summary file, so maybe this isn’t a decent argument, since the size difference would be on the order of tens of bytes. Philip
Attachment:
signature.asc
Description: This is a digitally signed message part