|
On 06/16/2016 03:09 PM, Alexander
Larsson wrote:
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.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 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. |
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
