Open Stack

[I'm Cc'ing you since you don't appear to be subscribed to
openstack-discuss, but please reply to the list rather than to me
directly.]

On 2023-04-18 12:42:46 +0000 (+0000), Vanou Ishii (Fujitsu) wrote:
[...]
> In the past, I faced situation to handle vulnerability in which
> cause of vulnerability is in vendor library but, to handle
> vulnerability, both OpenStack code and vendor library code should
> be modified. To handle this, I consulted community member and
> asked them to coordinate to fix vulnerability in private way (i.e.
> review patch and prepare commit in not public but private as usual
> security handling manner). However member are not willing to
> working on together because cause of vulnerability is in vendor
> provided library. I felt it’s better for community to, at least,
> be open to working on such vulnerability because that policy may
> benefit community. So I think it’s better to include policy in VMT
> document[1] like “Community is encouraged to make effort to be
> open to handling vulnerability in which both OpenStack community
> code and vendor provided code should be modified”.
> 
> How do you think about this?
[...]

I think it depends a great deal on the specifics of the bug and the
proposed solution. OpenStack has backport policies which attempt to
avoid introducing regressions or disruptive behavior changes in
stable branches, so there are limits as to what can be changed
through the backporting process. For fixing in the version of
OpenStack services under development (currently 2023.2 "bobcat"),
there is more leniency but it's still up to the core reviewers of
that project as to what sorts of solutions they're willing to
incorporate into their software in order to cater to changes in
externally-developed device drivers.

It sounds like you have a security vulnerability in a device driver,
and fixing it will also require some changes to an OpenStack
service, is that correct? If so, follow the recommended reporting
process[*] ideally opening a bug in Launchpad or creating a story in
StoryBoard depending on where that project's defect tracking is
managed. If the affected repository is not officially overseen[**]
by the OpenStack Vulnerability Management Team, you can still
explicitly subscribe them (~openstack-vuln-mgmt in Launchpad or
openstack-security in StoryBoard) and we'll try to assist with
coordination on a best effort basis.

[*] https://security.openstack.org/#how-to-report-security-issues-to-openstack
[**] https://security.openstack.org/repos-overseen.html
-- 
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/20230418/7861003f/attachment.sig>