On Wed, 2017-06-07 at 21:33 -0400, Colin Walters wrote:
On Wed, Jun 7, 2017, at 01:16 PM, Philip Withnall wrote:Correct, this is all verify-and-trust-on-first-use. If we later add the official gnome-apps, we’ll end up in the situation where two locally configured remotes have the same origin ID. That’s not something I want to disallow (they might be the new and old locations for the content, for example), but it could potentially be used as a red flag that something a bit odd is going on. I think that’s something to explore in future.Broadly speaking we've been talking about a model where *after* the user has a given (collection id, ref) pair, they can update that pair from any set of remotes that provide it.
Yes, that’s definitely the use case I’m focusing on most. However… (Aside: as things currently stand, the user/gnome-software would still give a (remote name, ref) pair; the remote name would be converted to a collection ID internally using the local configuration.)
But just to clarify something - we're not talking about doing anything P2P/discovery for *new* ref installs?
Installing an app from P2P should be possible, but it requires a remote to be configured with that collection ID first (so we have a GPG key to use). That would typically happen by the user adding a .flatpakrepo or .flatpakref file (which is why these files need to support setting the collection ID). With that configuration, the ref can be resolved as (new remote name, ref) as in the update case. This should be possible even if the newly configured remote isn’t actually accessible (e.g. there is no internet connection), since the configuration for it is all local.
Basically, `flatpak install` would still require a (remote, ref) pair?
Yes.
Or are we scoping in here simply installing "ref" and having that be discovered too and automatically bound to a remote if we happen to have a remote available that provides it?
Nope, that’s not part of the plan, because (ref) by itself is not globally unique, and if no remote has been configured for it, there has been no opportunity for the user to verify it. Philip
Attachment:
signature.asc
Description: This is a digitally signed message part