Re: Redistributing refs from multiple origins in a single repository

[Colin Walters <walters verbum org>]

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.

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.

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.

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?

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"?