<div dir="ltr"><div>I've reviewed the requirements, and it's my intention to set Ironic as under the VMT. I'll wait until it can be announced at Monday's meeting to make it official so folks can have a chance to object if they wish.</div><div><br></div><div>-</div><div>Jay Faulkner</div><div>Ironic PTL</div><div>TC Member<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 27, 2023 at 10:26 AM Jeremy Stanley <<a href="mailto:fungi@yuggoth.org">fungi@yuggoth.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2023-02-27 08:16:50 -0800 (-0800), Jay Faulkner wrote:<br>
[...]<br>
> Is there any reason Ironic should not be vulnerability-managed? Is the<br>
> security team willing to have us?<br>
<br>
As long as you make sure you're good with this checklist, just<br>
propose the specific repositories in question as an update to the<br>
top section of the document (in openstack/ossa):<br>
<br>
<a href="https://security.openstack.org/repos-overseen.html#requirements" rel="noreferrer" target="_blank">https://security.openstack.org/repos-overseen.html#requirements</a><br>
<br>
> The only potential complication is that Ironic may receive reports<br>
> for vendor libraries used by Ironic but not maintained by<br>
> Ironic -- I was hoping there might already be some historical<br>
> precedent for how we handle those; it can't be that unique to<br>
> Ironic.<br>
[...]<br>
<br>
    2. The VMT will not track or issue advisories for external<br>
    software components. Only source code provided by official<br>
    OpenStack project teams is eligible for oversight by the VMT.<br>
    For example, base operating system components included in a<br>
    server/container image or libraries vendored into compiled<br>
    binary artifacts are not within the VMT’s scope.<br>
<br>
Receiving bug reports about such things is fine, but the VMT doesn't<br>
coordinate those reports nor issue official security advisories<br>
about them since they need fixing by their upstream maintainers with<br>
whom we have no direct relationship. You can still propose security<br>
notes urging operators to update software in those situations, if it<br>
seems appropriate to do so:<br>
<br>
<a href="https://wiki.openstack.org/wiki/Security_Notes" rel="noreferrer" target="_blank">https://wiki.openstack.org/wiki/Security_Notes</a><br>
<br>
-- <br>
Jeremy Stanley<br>
</blockquote></div>