On 06/16/2016 05:57 PM, Gerald Henriksen wrote:

On Thu, 16 Jun 2016 15:44:11 -0400, Przemek 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.

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.

To me though you are talking about an ideal world where everything is
properly packaged into rpms and everybody deals with security issues
promptly.

There is a lot of evidence however that we aren't living in such an
ideal world, and as a result there is a lot of software installed
outside of rpms that rarely gets updated.

How much of this self installed software would get updated when the
next vulnerability is found (or for that matter, how much self
installed software still has old bundled SSL exposing systems)?

The way I see it is the single-distribution model turned out to be too difficult to third party software authors, who just couldn't provide packages for every distribution in a fragmented marketplace. At the same time, the distributions like Fedora don't have the manpower to do the packaging work for everyone. Therefore, we the users started loading random configure+make/npm/pip/curl|sh stuff.

The container plan promises a solution by offering portable packages, so the software authors have to only do the packaging once. That makes sense, and will probably work for the authors. In any case, it's got to be a better situation than the configure+make world.

My concern is that everyone is focused on production and delivery, but not necessarily on maintenance. For instance, the consumers/end users need to be able to assess the vulnerability of their setup and patch what's necessary. The single distribution model works well for that: you just inspect all the packages you have. In principle, the model of multiple container sources is also discoverable, but the responsibility for properly packaging, describing and maintaining things is diffused among multiple parties.

I think by now the tea leaves can be read: containers are going to be with us. I just hope that people would see the need for discipline and cooperation so that the resulting containerized systems are as easy to maintain as the unified distributions.

The best case is we'll have an ecosystem of universal portable packages updated for every possible environment. The worst case is like the huge FTP repositories of abandoned, redundant Visual Basic programs of the early '90s. I sure hope for the best.

So while Snap / Flatpak / Docker may mean 50 different copies of a
library need to be fixed, the fact that those packagers (presumably
being as responsible as existing rpm maintainers) actually release new
fixed versions might actually mean systems will be far more secure
than currently.

Exactly! it turns out that making the thing in the first place is the easy part; taking care of it during its lifetime is the hard part. Reminds me of parenting.