On Thu, 2017-06-01 at 21:17 -0400, Colin Walters wrote:
On Sat, May 27, 2017, at 06:53 PM, Philip Withnall wrote:In addition, an origin ID needs to be included in the commit metadata, paired with each ref name; otherwise an attacker could make a commit from one origin (in a P2P server) be pointed at by an identically named ref in another origin. This situation is not as rare as one might think: it could easily apply to the `appstream/$arch` branches which flatpak uses.This part still seems vague to me, though I may just need more time to think about it.
This bit is just an application of the principle of extending all refs to be (origin ID, ref name) tuples.
What I was getting hung up on downthread with making the origin ID actually just *be* the key is that if they're distinct, we need to track a binding between the origin ID and the GPG key.
Indeed. In my current proposal, this binding is given by the repository configuration ($repo/config file), as set up by the user (potentially by using a .flatpakrepo file). A [remote "blah"] section contains a key for the GPG keyring (as currently) and a key for the origin ID (new).
So in your proposed scheme, the origin ID is an arbitrary string signed by the key. And that signature is maintained in both the summary and per-commit it sounds like. The more we can think of the summary as a cache, the better. So let's say per-commit.
Not quite. The origin ID is an arbitrary string. It’s signed by the key because we can — this gives proof of the key owner’s claim to own the origin ID. It doesn’t give proof that they are the only key owner claiming to own it. The signature is maintained in the summary file in the proposition as it currently stands. I guess if we add the origin ID to the ref name in commit metadata, it will get signed, and hence that does act as a per-commit signature for the origin ID. That’s fine, but it wasn’t the original intention.
And what I'm having trouble thinking about right at this moment is: what happens when one has two remotes (say gnome-apps and github.com/exampleapp/foo), each with their own keys, and then later github.com/exampleapp/foo is compromised, and generates an `org.gnome.gedit/x86_64/stable` ref underneath their origin? What happens if they update their summary or commits to sign the `gnome-apps` origin ID string?
That’s a valid attack. It’s mitigated by the fact that the origin ID has to be configured in a [remote "blah"] section in the user’s repository config file in order to be used. So in this case, the config file should contain something like: [remote "my-gnome-apps"] url=https://gnome.org/blah/blah origin-id=gnome-apps gpg-keyring=gnome-apps.gpg [remote "my-github.com/exampleapp/foo"] url=https://github.com/exampleapp/foo origin-id=exampleapp # for example; definitely not ‘gnome-apps’ gpg-keyring=exampleapp.gpg When resolving the ref ‘org.gnome.gedit/x86_64/stable’ for remote ‘my- gnome-apps’, the origin ID ‘gnome-apps’ and GPG keyring would be looked up from the configuration file, and they’re what would be used to resolve LAN/USB/whatever mirrors of that ref. Anything from the compromised github.com/exampleapp/foo would match the ‘gnome-apps’ origin ID, but the keys wouldn’t match and hence signature validation would fail.
Is it that the origin ID has to match the remote name? Parts of the text below sound like that is the case. But then if that's the case, why aren't we just calling it a "signed remote name"?
The original proposal I made in this thread gave two options for the binding between origin IDs and remote configuration: - have origin IDs and remote names match; or - explicit configuration. I was initially going with the first option, but the implementation turned out to not be so good (since that means it’s impossible to enumerate the remotes which have an associated origin ID). So, I’ve switched to the section option: requiring the origin ID to be explicitly configured in the [remote "blah"] sections in the $repo/config file. A [remote "blah"] section can omit an origin ID — that means P2P support won’t be available for it. I hope that clears things up? Philip
Attachment:
signature.asc
Description: This is a digitally signed message part