On 06/16/2016 03:09 PM, Alexander Larsson wrote:
On Thu, 2016-06-16 at 14:07 -0400, Przemek Klosowski wrote:
I think that once the full sandboxing / portal system is in place,
there _will_ be a tangible reason to prefer Flatpak.
 Definitely true for third party packages that currenly require
pip/npm/rubygems/(curl | sh  :), but you seem to be saying that
Flatpack will be preferable even when there's an existing  Fedora
package. I think this needs to be well justified: security is a mixed
bag (RPMs can have sandboxing via SELinux and otherwise, and
containers/flatpacks complicate security updates), and other aspects
also seem to have balancing pros and cons.
You seems to think about a different "security" than what flatpak
provides. Say you run a game, packaged by fedora. Its nicely packaged
and reviewed, so you're not running unreviewed, unsigned scripts as
root to install it. This is traditional "unix security". 

However, if the game talks to the network and has bug, it can still
easily be attacked and the resulting powned process has full access to
your ssh keys, your email containing private info, your gpg agent, etc,
etc.
I get that, but as I said, RPM can have sandboxing too, and so far it looks like the main vulnerability vector is unpatched software. Flatpack wouldn't have helped with heartbleed, and the right remediation for it was rapid patching---which was hampered by all the bundled SSL libraries even without many containers in the mix.

I do see the utility of containers, and realize that properly curated containers can be patched as well as native packages. It's just that I am concerned that they will diffuse responsibility for patching so much that effectively curation will fail.