On Tue, 2017-03-28 at 22:15 -0400, Colin Walters wrote:
[Will try to contain my use of characters to boring old ASCII]
[Me too :-(]
On Tue, Mar 28, 2017, at 06:20 PM, Philip Withnall wrote:Exploring other solutions makes sense. GPG keys and repository identification are not entirely orthogonal in this situation, since if we're going to support downloading objects from untrusted hosts on the local network (rather than a trusted central server), GPG signing is mandatory, and hence a GPG key will always be present as a bit of shared data between the client and the remote.Right, I agree with that. It feels like perhaps what we should have done from the start is to bind *ref* to GPG key. That'd be somewhat ugly to retrofit now though.
In the sense that each ref has a different GPG key; or in the sense that the ref name is a key ID? In either case, commits would need to support being signed by multiple keys (which I assume they do already by appending the signature packets in the .sig file?). Are you suggesting this because of the way flatpak uses OSTree --- one repository which deduplicates files from various separate applications, each of which has its own ref, and theoretically is its own security domain?
Using a GPG key is basically equivalent to your previous suggestion of a UUID per repository. I decided that a GPG key would be a bit more usable, since a UUID is an additional bit of incomprehensible-hex- string to be associated with each repository. However, this comes at the cost of somewhat overloading the semantics of GPG keys. I would be OK with using a UUID instead, if you want to bypass the semantic issue here.UUID-in-repo definitely has its own set of problems, let's dive into the below more a bit:
Thinking about the above keys-for-refs idea highlights the fact that using a GPG key as an identifier also falls over when a repository is signed by more than one key. Which one is the identifier in that case?
Not quite. Resolving the ref to a commit hash needs to involve all the potential remotes, since they might all resolve it differently, and some remotes might resolve it to a more recent commit than others.What I was proposing is that the client contacts the "canonical remote" first. This is in line with my proposal in [previous discussions](ht tps://mail.gnome.org/archives/ostree-list/2016-October/msg00002.html) around mirroring - the mirrorlist or "fetch objects from multiple places" is for *content* - we would still retrieve the summary/commit metadata+signature from the more-strongly- protected metadata part of the remote. See also https://github.com/ostreedev/ostree/issues/707
That's a valuable use case, but not the one I am trying to address here. The use case I am trying to address is for updating *without* a connection to the internet. For example, a machine is initially installed, and has no internet access. It needs to be regularly updated from a USB stick. Or, a lab full of machines are installed and are connected in a local network. One of the machines has access to the internet to update from; the other machines need to be able to pull updates from it. Or, a machine without internet access has a flatpak app installed on it from a USB stick. A month later, the machine gets internet access (which has just been installed in the building, or something), and should be able to update that flatpak app from the internet from that point onwards. The final use case is particularly interesting, because it motivates the need to resolve the remote differently each time a pull is done — initially the remote is a USB stick; then it's a canonical server on the internet. For completeness, I also care about these use cases: - Internet connection is always available; OSTrees are always updated from the internet. - Internet connection is available, but so are other peers on the local network, and so downloads could be sped up by downloading from them all in parallel. (This is a 'nice to have', either now or later.) - At a conference, I want to easily share an OSTree repository with someone without having to upload it to the internet and then download it again.
Put differently, the decision about which URI to pull from, and which other URIs to consider as mirrors of it, needs to be taken only after the summary information is available from each remote. As far as I understand, mirrorlists do not do that (nor do we want them to?).We could. https://github.com/ostreedev/ostree/issues/687 is also a bit related to this. But this is all a bit of an aside - if we do the "retrieve commit hash from canonical remote, try finding commit in local mirrors" model, it wouldn't apply.
As above, using the canonical remote is not an option for Endless' use cases. :-( Philip
Attachment:
signature.asc
Description: This is a digitally signed message part