On Thu, 2017-06-01 at 12:44 -0400, Colin Walters wrote:
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.
To me, it sounds like a ‘vendor’ is someone who would have a ‘collection’ of things. I think I still lean towards ‘collection’. (Again, I’m going to continue using ‘origin’ in this e-mail for consistency in the thread.)
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.
For sure. I don’t think there’s a problem here. For the case of newly- configured repositories, the origin ID can come from the .flatpakrepo file which is being used to set up the repository. For systems which already have repositories configured, flatpak already has a mechanism to update repository configuration from the origin’s summary file, so that should eventually pull in the origin ID from any origin servers which add it to their summary files. This doesn’t help in the case of already-existing P2P systems with no internet connection, but they don’t really exist yet (at least, the Endless OS ones which do, we can take care of within Endless OS).
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.
For clarity, ‘this’ is the idea of GPG key rotation for the purposes of using GPG key IDs as the origin IDs; right? As I said (covered below), I don’t really want to pull GPG into this layer of addressing.
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.
I don’t think it simplifies much. With the branch I have at the moment (which implements most of this thread in OSTree, in an unpolished but functional state), the function which maps origin IDs to GPG keys is ~50 lines long. If I’m thinking straight, that’s the only code which would be eliminated by using the GPG key ID as the origin ID. I guess the other advantage is that it makes proofs of ownership of the key a bit easier (just look at the key ID, rather than checking a signature on the origin ID).
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.
Right. There’s also the case where you want all your commits to be signed by two keys (say, the key of the original flatpak packager, and the key of the redistributor). In that case, which key is used as the origin ID? I really don’t feel that using key IDs as origin IDs is going to solve more problems than it causes.
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?
But that takes us right back to the current state of allowing arbitrary strings as the origin ID. Philip
Attachment:
signature.asc
Description: This is a digitally signed message part