Hi, I'm trying to find a way to make installation of flatpak applications as simple as possible. LibreOffice for Flatpak has been out for a couple of months and the feedback is that the installation process is too complex. It has improved with GNOME Software 3.22 supporting flatpak bundle installation. But you still have to manually add a remote with required runtime and install that runtime if it's not already installed.
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.
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. 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. But that's not the case for many apps now.
It's basically enabling 3rd party software sources which requires an approval of the Workstation Working Group if I understand it correctly. So I'd like to propose this for discussion in the working group.
Jiri
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?
On 11/08/2016 01:30 PM, Matthew Miller wrote:
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?
I'm not sure that's a reasonable question on which to base the decision, since that isn't necessarily true of the flatpak's they're installing either.
Matthew Miller píše v Út 08. 11. 2016 v 13:30 -0500:
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?
Do we really require the same from other 3rd-party software? I wouldn't mind a big fat warming "You're installing a 3rd-party app which will pull in a 3rd-party runtime, Fedora takes no responsibility for those".
Like with other 3rd-party software, I think it's better if we help users download the runtime from the official repository than letting them find it in the wild.
Don't get me wrong, I have nothing against reasonable criteria for inclusion, but without double standards.
Jiri
On Wed, Nov 9, 2016 at 7:58 AM, Jiri Eischmann eischmann@redhat.com wrote:
Matthew Miller píše v Út 08. 11. 2016 v 13:30 -0500:
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?
Do we really require the same from other 3rd-party software? I wouldn't mind a big fat warming "You're installing a 3rd-party app which will pull in a 3rd-party runtime, Fedora takes no responsibility for those".
The word "trusted" actually has meaning. It can mean we (the Fedora project) believe the application being provided is of high quality and known to work. It can mean it is secure and will not install rootkits or leak privacy information. It can mean a lot of things. However, you absolutely cannot call it trusted and slap a big fat warning on it disavowing it as 3rd-party with no responsibility from Fedora.
So either they are trusted to some degree or they are not. Words mean things.
Like with other 3rd-party software, I think it's better if we help users download the runtime from the official repository than letting them find it in the wild.
Don't get me wrong, I have nothing against reasonable criteria for inclusion, but without double standards.
You're raising the standards by calling something trusted. If it isn't trusted, don't call it as such.
josh
After playing with flatpak recently, I found the UX not that friendly, so I agree and think your proposal makes sense. (Though I haven't played much with installation through Gnome Software.)
Jens
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. I think all that matters are runtime ID and version, AFAIK GPG only checks if the runtime comes from the remote it claims it does. Yes, there could be a safety catch that would prevent updating the runtime from a different remote than the original one.
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.
Adding a runtime is not so simple procedure right now and the user has to perform the steps. If a remote is added and a runtime installed automatically as a part of app installation, they may not even know something like this is happening. Neither option is fixing all potential security issues, but there will always be some with installing 3-rd party software.
Jiri
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. I think all that matters are runtime ID and version, AFAIK GPG only checks if the runtime comes from the remote it claims it does. Yes, there could be a safety catch that would prevent updating the runtime from a different remote than the original one.
I think this is quite essential to have. It would allow automatic runtime installation without any questions asked, which is something I expected (or at least hoped for) from flatpack. I want to download a file and double click on it. I don't want to decide whether remote X needed for runtime Y is trustworthy or not. The user should not even know what a runtime is, it should be completely transparent :)
I'm no security expert but in my naive world it shouldn't be too hard to make sure that remotes can't supply updates for runtimes from other remotes, using digital signatures.
On ons, 2016-11-09 at 16:43 +0100, Jiri Eischmann wrote:
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.
No, that will not work. When you install an app or a runtime you have to specify a remote to install it from. This is a trusted operation and after that we will *only* update that app/runtime from that remote.
The problem is when the runtime is *not* installed. The untrusted remote could claim to have an "org.gnome.Platform" runtime, which will then be installed, and at this point you're affecting another app.
So, the most important points of trust is when you initially install something, as that ties it to the remote and thus the GPG key. Also somewhat important is when you add a remote that is used for depencency resolution. Such auto-dependencies always show the name of the remote that the dependencies will be installed from, so a vary user will detect strange things, but its easy to overlook this and say "yes" without thinking.
On 11/17/2016 10:48 AM, Alexander Larsson wrote:
The problem is when the runtime is *not* installed. The untrusted remote could claim to have an "org.gnome.Platform" runtime, which will then be installed, and at this point you're affecting another app.
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?
On Thu, 2016-11-17 at 11:38 +0100, Kalev Lember wrote:
Is it possible to use cryptography here to make this a bit more safe and easier to use?
We can preinstall selected GPG public keys. I think the solution is to simply forbid installation of flatpaks if the runtime is not on some preinstalled list of known runtimes/keys. I do not want to design yet another "click through this security warning" system.
On tor, 2016-11-17 at 11:38 +0100, Kalev Lember wrote:
On 11/17/2016 10:48 AM, Alexander Larsson wrote:
The problem is when the runtime is *not* installed. The untrusted remote could claim to have an "org.gnome.Platform" runtime, which will then be installed, and at this point you're affecting another app.
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.
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.
I think the idea wasn't that Fedora carries a list a known runtimes and their keys, but the app manifest itself specifies the required runtime and its key (this would be mandatory). So it's a) distributed and b) the runtime can't be subverted for any app. But it would also mean that runtimes of the same name would have to be parallel installable (otherwise someone decides to rebuild and host the gnome platform on their own, but not change the name, and then we have a collision and a problem).
On Tue, 2016-11-08 at 19:14 +0100, Jiri Eischmann wrote:
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.
Yes. That's not acceptable. Third-parties surely must use some predefined set of runtimes to be compatible with Fedora.
Previously it was proposed that we would support only Fedora runtimes, but no third-party developers will use that so I think it's a bad idea.
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?)?
Michael
On ons, 2016-11-09 at 11:28 -0600, Michael Catanzaro wrote:
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?)?
Clearly we can't support old gnome releases released every 6 months forever. However, i think there is a sort of automatic resolution to this, because in general apps that target the gnome/kde platform rev pretty often because they follow the evolution of the platform. So, not a lot of gnome apps are going to use old gnome runtimes.
Still, you may want to use an old app, and thus an old platform. But the question then becomes, what does support even mean if you're not even using the latest update version of the app?
For apps that are less tied to the gnome or kde platforms, targeting the freedesktop runtime might be better.
That said, some kinds of apps may want more platform libraries, yet still not rev that often. For such apps i guess defining some versions of the gnome/kde platforms as "more LTS" than others make sense.
There has also been discussions about creating an official "LTS" flatpak runtime, based on some centos7 version, which would have a really long support time, due the the centos base. I don't know what the state of this is apart from it being "in discussion".
Jiri Eischmann píše v Út 08. 11. 2016 v 19:14 +0100:
Hi, I'm trying to find a way to make installation of flatpak applications as simple as possible. LibreOffice for Flatpak has been out for a couple of months and the feedback is that the installation process is too complex. It has improved with GNOME Software 3.22 supporting flatpak bundle installation. But you still have to manually add a remote with required runtime and install that runtime if it's not already installed.
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.
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. 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. But that's not the case for many apps now.
It's basically enabling 3rd party software sources which requires an approval of the Workstation Working Group if I understand it correctly. So I'd like to propose this for discussion in the working group.
Jiri
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.
Jiri
On 10 November 2016 at 11:43, Jiri Eischmann eischmann@redhat.com wrote:
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.
Really? It should work in gnome-software; I know there at least used to be a unit test for this.
Richard
On Fri, 11 Nov 2016 17:50:38 +0100, Richard Hughes hughsient@gmail.com wrote:
On 10 November 2016 at 11:43, Jiri Eischmann eischmann@redhat.com wrote:
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.
Really? It should work in gnome-software; I know there at least used to be a unit test for this.
Richard _______________________________________________
I think there's a problem with the GPG signature of the KDE Flatpak repo. There's no report about any error in Software though so I don't know if that's actually the reason why it doesn't work.
desktop@lists.stg.fedoraproject.org
-
Alexander Larsson -
Jens-Ulrik Petersen -
Jiri Eischmann -
Josh Boyer -
Kalev Lember -
Kamil Paral -
Martin Bříza -
Matthew Miller -
Michael Catanzaro -
Richard Hughes -
Stephen Gallagher