<div dir="ltr">I've been out on vacation but as a circle back to normal (working!) life I've found this thread very interesting. <div><br></div><div>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.</div><div><br></div><div>Perhaps it would be useful for a spec around this, so we could collaborate in a more structured way?</div><div><br></div><div>-Rob</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 24, 2017 at 3:54 PM, Jeremy Stanley <span dir="ltr"><<a href="mailto:fungi@yuggoth.org" target="_blank">fungi@yuggoth.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2017-05-24 14:22:14 +0200 (+0200), Thierry Carrez wrote:<br>
[...]<br>
<span class="">> we ship JARs already:<br>
> <a href="http://tarballs.openstack.org/ci/monasca-common/" rel="noreferrer" target="_blank">http://tarballs.openstack.org/<wbr>ci/monasca-common/</a><br>
</span>[...]<br>
<br>
Worth pointing out, those all have "SNAPSHOT" in their filenames<br>
which by Apache Maven convention indicates they're not official<br>
releases. Also they're only being hosted from our<br>
<a href="http://tarballs.openstack.org" rel="noreferrer" target="_blank">tarballs.openstack.org</a> site, not published to the Maven Central<br>
Repository (the equivalent of DockerHub in this analogy).<br>
<span class=""><br>
> That said, only a small fraction of our current OpenStack deliverables<br>
> are supported by the VMT and therefore properly security-maintained "by<br>
> the community" with strong guarantees and processes. So I don't see<br>
> adding such binary deliverables (maintained by their respective teams)<br>
> as a complete revolution. I'd expect the VMT to require a lot more<br>
> staffing (like dedicated people to track those deliverables content)<br>
> before they would consider those security-supported.<br>
<br>
</span>The Kolla team _has_ expressed interest in attaining<br>
vulnerability:managed for at least some of their deliverables in the<br>
future, but exactly what that would look like from a coverage<br>
standpoint has yet to be ironed out. I don't expect we would<br>
actually cover general vulnerabilities present in any container<br>
images, and would only focus on direct vulnerabilities in the Kolla<br>
source repositories instead. Rather than extending the VMT to track<br>
vulnerable third-party software present in images, it's more likely<br>
the Kolla team would form their own notifications subgroup to track<br>
and communicate such risks downstream.<br>
<span class="HOEnZb"><font color="#888888">--<br>
Jeremy Stanley<br>
</font></span><br>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br></div>