Re: Redistributing refs from multiple origins in a single repository

[Colin Walters <walters verbum org>]

On Thu, Jun 1, 2017, at 08:41 AM, Philip Withnall wrote:
> 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’?

"vendor"?  I often use the term "OS vendor" for the ostree-as-host case.

> Aside: In the Endless OS case, we would have the flatpak repos/OSTree
> repos defined already.

Right.  Handling the non-predefined case correctly seems to me to be
 pretty important though for the general success of flatpak at least.

(The non-predefined case for ostree-as-host is...way too special/weird 
 to worry about a lot )

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

What I was going for by bringing up commits is the other thread
where we were talking about support for transitioning things (GPG keys,
repo locations, and things like the endoflife rebase).

That content itself definitely needs to be signed, and hence we were
iterating towards including it in commits since those are already signed.

Now, the other thing you brought up is individually signed components
in the summary file, which would be another way to address this.
> 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.

I understand that, but on the other hand it seems to me a lot of
things could be simpler if the collection/vendor ID *is* the latest GPG key fingerprint.

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

Having signatures be detached and supporting multiple in ostree is
precisely for this reason - one can take a tested "beta" commit and simply
add a "gold" signature to it.

That said, honestly I think in practice it's better to take the same *content*
but make a new commit.   This ensures that the commit history is linear.
See https://github.com/ostreedev/ostree-releng-scripts/blob/master/do-release-tags
which was mentioned in the other thread too.

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

Yes; a common case for this might be a vendor who wants their OS
repository and flatpak repositories separate, but sign with the same key.
But solving that is simply making the vendor ID "$remotename-$fingerprint"
right?

(If we assume that we can't/shouldn't change $remotename, i.e.
 `gnome-apps` will stay that way and not become e.g. `org.gnome.apps`)