Re: Redistributing refs from multiple origins in a single repository

[Colin Walters <walters verbum org>]

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

That aside, you're saying we'll keep *trying* to pull content from there and failing
due to bad signatures?

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.

Which...maybe we can't avoid that, but I'm just trying to understand the
semantics.

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?