Open Stack

Security is a spectrum, not a boolean. I know some sites that have instituted super long/complex password requirements. The end result is usually humans just writing pw's down on stickies then since its too hard to remember, making security worse, not better. Humans are always the weakest link in the security system and must be taken into account.

There are people that will do things insecurely. If we can make it much easier for them to get access to much more fresh stuff rather then build it themselves (which they wont), the community as a whole will be better off. There will be far fewer clouds out there with known bad CVE's baked in.

Lets provide the tools to make it as easy as possible to identify containers with issues, and allow upgrading the system to newer ones.

Which CVE's are on the system is somewhat less important then being able to get to newer versions installed easily. Right now, thats probably harder then it should be. If its hard, people won't do it.

Fresh images are just a step in that process.

Thanks,
Kevin
________________________________________
From: Jeremy Stanley [fungi at yuggoth.org]
Sent: Tuesday, May 16, 2017 12:36 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

On 2017-05-16 11:46:14 -0700 (-0700), Michał Jastrzębski wrote:
[...]
> So CVE tracking might not be required by us. Since we still use
> distro packages under the hood, we can just use these.
[...]

I think the question is how I, as a semi-clueful downstream user of
your images, can tell whether the image I'm deploying has fixes for
some specific recently disclosed vulnerability. It sounds like your
answer is that I should compare the package manifest against the
versions listed on the distro's CVE tracker or similar service? That
should be prominently documented, perhaps in a highly visible FAQ
list.

> Since we'd rebuild daily, that alone would ensure timely update to
> our containers. What we can promise to potential users is that
> containers out there were built lately (24hrs)
[...]

As outlined elsewhere in the thread, there are a myriad of reasons
why this could end up not being the case from time to time so I can
only assume your definition of "promise" differs from mine (and
unfortunately, from most people who might be trying to decide
whether it's safe to rely on these images in a sensitive/production
environment).
--
Jeremy Stanley