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.