[openstack-dev] [release][tc][infra][security][stable] Proposal for shipping binaries and containers
hyakuhei at gmail.com
Fri May 26 14:20:12 UTC 2017
I've been out on vacation but as a circle back to normal (working!) life
I've found this thread very interesting.
I share the concerns raised about the level of resource required to back
this. I don't speak for the VMT but I agree with Jeremy that it should be
possible to provide VMT support to Kolla and their code base without
extending to the external libraries in their contain images. However, I'm
not sure that the limits of VMT coverage would be acceptable to downstream
stakeholders, for the reasons Doug has highlighted above.
Perhaps it would be useful for a spec around this, so we could collaborate
in a more structured way?
On Wed, May 24, 2017 at 3:54 PM, Jeremy Stanley <fungi at yuggoth.org> wrote:
> On 2017-05-24 14:22:14 +0200 (+0200), Thierry Carrez wrote:
> > we ship JARs already:
> > http://tarballs.openstack.org/ci/monasca-common/
> Worth pointing out, those all have "SNAPSHOT" in their filenames
> which by Apache Maven convention indicates they're not official
> releases. Also they're only being hosted from our
> tarballs.openstack.org site, not published to the Maven Central
> Repository (the equivalent of DockerHub in this analogy).
> > That said, only a small fraction of our current OpenStack deliverables
> > are supported by the VMT and therefore properly security-maintained "by
> > the community" with strong guarantees and processes. So I don't see
> > adding such binary deliverables (maintained by their respective teams)
> > as a complete revolution. I'd expect the VMT to require a lot more
> > staffing (like dedicated people to track those deliverables content)
> > before they would consider those security-supported.
> The Kolla team _has_ expressed interest in attaining
> vulnerability:managed for at least some of their deliverables in the
> future, but exactly what that would look like from a coverage
> standpoint has yet to be ironed out. I don't expect we would
> actually cover general vulnerabilities present in any container
> images, and would only focus on direct vulnerabilities in the Kolla
> source repositories instead. Rather than extending the VMT to track
> vulnerable third-party software present in images, it's more likely
> the Kolla team would form their own notifications subgroup to track
> and communicate such risks downstream.
> Jeremy Stanley
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev