On Wed, 2017-06-07 at 11:35 -0400, Colin Walters wrote:
On Mon, Jun 5, 2017, at 01:26 PM, Philip Withnall wrote: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.Because this user had the remote configuration saved, they wouldn't pick up the changes to the upstream? Yeah, although I can certainly imagine down the line flatpak having a mechanism to pull updated repo configs from upstream (e.g. to get updated descriptions).
Correct: because the configuration is saved locally, the user’s view of the origin ID for the compromised repository wouldn’t actually change. I gave the wrong impression in my last e-mail. If the user’s local configuration doesn’t change, the compromised repository won’t be returned when resolving refs for the ‘gnome-apps’ origin. Aside: flatpak already can pull updated config from repositories (see flatpak_dir_update_remote_configuration_for_summary() in https://github .com/flatpak/flatpak/blob/master/common/flatpak-dir.c). So far I deliberately haven’t updated the flatpak code to also update the origin ID in remote configuration when it changes in the remote’s summary file. Even if the origin ID is signed in the remote’s summary file, updating it would break the trust-on-first-use property you mention below.
That aside, you're saying we'll keep *trying* to pull content from there and failing due to bad signatures?
No, I was wrong in my previous e-mail. We would no longer try to pull content from the compromised repository, because our local value for its origin ID is not updated when the repository is compromised, so doesn’t match ‘gnome-apps’. In any case, we could check the inline signatures in the summary file while finding remotes (before starting to pull content) and discount any which fail before we try to pull from them. So if we do end up in the situation where an origin is resolved to a remote which is using an unexpected key, that remote is discounted from the results as part of the resolution process.
What about the case where the user adds `exampleapp/foo` after it's been compromised? It sounds like we're in a trust-on-first-use situation; adding the official gnome-apps will cause the inverse situation, we'll keep trying to pull from there and failing.
Correct, this is all verify-and-trust-on-first-use. If we later add the official gnome-apps, we’ll end up in the situation where two locally configured remotes have the same origin ID. That’s not something I want to disallow (they might be the new and old locations for the content, for example), but it could potentially be used as a red flag that something a bit odd is going on. I think that’s something to explore in future.
Which...maybe we can't avoid that, but I'm just trying to understand the semantics.
The semantics are, as you say, trust-on-first-use, and the user is responsible for verifying that the origin ID they trust is correct for the content they expect to get. This is the same model as flatpak uses already: currently, the user is responsible for verifying that any remote they add is trustworthy.
Does it help anything at all to invert things, and have something like ``` [remote "my-p2p-gnome-apps"] url=https://192.168.122.1/repo mirror-of=gnome-apps ``` Basically mirrors have to be explicitly specified, and "origin ID" becomes the remote name. That feels like it helps the code enumerate them?
I think I’ve solved the problem of enumeration using the explicit key the other way around. Explicitly configuring each P2P peer doesn’t really fit in with the way OSTree and flatpak use remotes — they both make various assumptions about remotes being fairly static and user- configured. I had a play with dynamic remotes in both code bases, and the changes did not look nice. Philip
Attachment:
signature.asc
Description: This is a digitally signed message part