(Re-replying because somehow my previous reply got turned into '[Invalid UTF-8]' and not much else.) On Tue, 2017-03-28 at 13:59 -0400, Colin Walters wrote:
On Mon, Mar 27, 2017, at 11:06 AM, Philip Withnall wrote:I think I’m going to put a branch together which adds a new URI scheme to libostree, of the form ‘ostree-gpg:ABC123’, where ABC123 is the GPG key ID for the repository to pull from. Resolving this URI would look for remotes which use that key...Eeek. I'm not saying it's fundamentally wrong, maybe we end up there, but I'd like to explore other solutions a bit more.
(trimmed something which might have lead to invalid UTF-8?) 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. 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.
The other problem related to this solution is that of key rotation.Yeah, among others. Let me strawman this: To fetch a given ref from a remote, we proceed as today and resolve ref -> commit hash. Then, we automatically try to fetch that commit from any locally mounted media (cheap). If that fails, we use network heuristics - try to fetch from local Avahi sources. This could maybe be implemented today by simply prepending them to a locally-generated mirrorlist, with the canonical upstream last.
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. Another strawman: local machine has commit A deployed; commit A is also in a repository on a mounted USB stick; commit B is in a repository on a network peer; and commit C is on another network peer. Commit C is more recent than commit B, which is more recent than commit A. Using a mirrorlist would incorrectly result in the locale machine only pulling commit A. 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?). Philip
Attachment:
signature.asc
Description: This is a digitally signed message part