Another solution would be shipping Fedora Workstation with trusted remotes with flatpak runtimes enabled. It's not a long list right now,

On Tue, Nov 08, 2016 at 07:14:37PM +0100, Jiri Eischmann wrote: > Another solution would be shipping Fedora Workstation with trusted > remotes with flatpak runtimes enabled. It's not a long list right > now, What criteria are there for "trusting" a runtime? Will users be able to trace the sources that these runtimes are created from and the build process used?

> One solution would be giving apps an option to add a remote and > install > the required runtime from it, but Alex sees that as a potential > security issue. Can you elaborate? What security issues?  Could installing runtime X subvert runtime Y used by other apps, e.g. by claiming that X is an update for Y? In that case I'd expect that GPG keys have to match, or something like that.

> If the required runtime were not in one of the trusted remotes, the > user would be told that the runtime was not found in trusted > remotes > and he'd have to install it manually before installing the app. How is this fixing the security issues? Most users will happily confirm a dialog, without studying key fingerprints etc.

Kamil Paral píše v St 09. 11. 2016 v 09:49 -0500: > > > > > One solution would be giving apps an option to add a remote and > > install > > the required runtime from it, but Alex sees that as a potential > > security issue. > > Can you elaborate? What security issues?  > Could installing runtime X subvert runtime Y used by other apps, > e.g. > by claiming that X is an update for Y? In that case I'd expect that > GPG keys have to match, or something like that. Yeah, the app requires the runtime X which is not installed and adds a remote to install it, but the remote could also contain a malicious version of the runtime Y which is already installed and used by other apps, and the malicious version overrides it as an update. Then other apps get infected.

Is it possible to use cryptography here to make this a bit more safe and easier to use?

> Is it possible to use cryptography here to make this a bit more safe > and > easier to use? Instead of just matching "org.gnome.Platform" name, > apps > could maybe also require that "org.gnome.Platform" is signed with a > certain key? And then we could do automatic install if we can find a > runtime with matching signature? Also, maybe different > "org.gnome.Platform" runtimes signed with different keys should be > parallel installable? We could pre-install a configuration for an individual runtime like org.gnome.Platform, which includes a GPG key, and then that could be used automatically. This essentially happens now I think. At least there was a discussion about including preconfigured remotes for fedora. However, assuming this is a runtime we know nothing about, and some app A depends on it. What prohibits app B to say it depends on that runtime name, but supplying a different url for it *and* a different GPG key.

On Tue, 2016-11-08 at 19:14 +0100, Jiri Eischmann wrote: >  > > Another solution would be shipping Fedora Workstation with trusted > remotes with flatpak runtimes enabled. It's not a long list right > now, > pretty much just: FreeDesktop.org, GNOME, and KDE. Vast majority of > existing flatpak apps are using runtimes provided by these. If > those > remotes were enabled in Workstation by default, then installing a > flatpak bundle such as LibreOffice would be just a matter of > double- > clicking the file and approving the operation because > Software/Flatpak > could figure out the rest including installation of a runtime from > one > of the trusted remotes. I see half of a proposal here. You want FreeDesktop.org, GNOME, and KDE runtimes. Great, I agree. But we need to decide on which versions of those runtimes we will provide. FreeDesktop runtime is supposed to be an LTS, so we probably want to support all versions of that, whenever they are. But we can't support a new GNOME runtime every six months, nor a new KDE runtime every six weeks. So we have to make some decision on which versions are supported, and for how long, which versions are not supported. And that has to happen upstream of Fedora, or the "your app runs everywhere" compatibility guarantee goes out the window. My suggestion would be to have one GNOME LTS release every two years. I'll suggest eventually using the second release every odd-numbered year, to time it before an Ubuntu LTS, but we could bootstrap it with GNOME 3.22 or GNOME 3.24 or whichever. Then we'd support each of those for, say, 5 or 10 years, and not any versions in between. Ideally that would all be discussed and agreed upstream, so that other distros will follow what we do. What do you think about this approach? What do the other stakeholders think (Alex?)?

We just found out that there is still one prerequisite for this missing. Neither flatpak nor GNOME Software can install the required runtime even if there is a repo, that contains it, enabled.