Open Stack

On 2023-04-19 14:18:32 +0000 (+0000), Vanou Ishii (Fujitsu) wrote:
[...]
> I have already fixed that vulnerability and fix patch was merged
> into OpenStack project. In that case, patch review was held in
> public even that patch was related to vulnerability fix.

Note that it's preferable for most vulnerability fixes to be
developed in public, since private embargoes are extremely
inconvenient and taxing on our community. Only the most severe of
vulnerabilities need secrecy and rigorous coordinated disclosure.

I like to refer folks to this article on "the hidden costs of
embargoes" which does a great job of explaining the delicate balance
we try to strike in deciding which process to follow for each bug:
https://access.redhat.com/blogs/766093/posts/1976653

> What I would like to say is following:
> 
> "I think it's good idea to add policy to OpenStack security
> document[1]. That policy is OpenStack community is encouraged to
> be open to handle vulnerability which needs fix both in OpenStack
> code and vendor library code if that vendor library takes good
> role in that OpenStack project."
> 
> Above idea comes because when I consulted OpenStack project member
> about vulnerability fix whose root cause is in vendor library but
> both OpenStack code and vendor library, member was not open to
> collaborate working on vulnerability.
> 
> Is such addition to OpenStack security document reasonable? I ask
> this because there was discussion, in my colleague team, about
> there is no explicit description to openness to working on such
> situation in OpenStack doc.
[...]

As a community we expect our projects to be open to collaboration
with everyone; it's one of our founding principles:

https://governance.openstack.org/tc/reference/principles.html#contribution-is-our-currency

Security vulnerabilities are just bugs, and our projects are
expected to be open to collaborating with members of the community
on bug fixes. However, individual contributors decide their
priorities and get to choose what they spend their time working on.
Just because one contributor wasn't interested in collaborating on a
specific bug fix doesn't mean others won't assist. Reaching out to
project leadership when you have concerns over prioritization is the
most effective way to make progress.

This doesn't really seem to me to have anything to do with security
vulnerabilities, and so I don't think that adding collaboration
recommendations to our vulnerability reporting guidelines or to our
vulnerability coordination process document would make sense. These
principles apply everywhere, not just to security fixes.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230419/47e3670a/attachment.sig>