[nova][ops] EOL'ing stable/train ?
Hi folks, in particular operators... We discussed yesterday during the nova meeting [1] about our stable branches and eventually, we were wondering whether we should EOL [2] the stable/train branch for Nova. Why so ? Two points : 1/ The gate is failing at the moment for the branch. 2/ Two CVEs (CVE-2022-47951 [3] and CVE-2023-2088 [4]) aren't fixed in this branch. It would be difficult to fix the CVEs in the upstream branch but hopefully AFAIK all the OpenStack distros already fixed them for their related releases that use Train. So, any concerns ? TBH, I'm not really happy with EOL, but it would be bizarre if we say "oh yeah we support Train backports" but we don't really fix the most important issues... -Sylvain (who will propose the train-eol tag change next week if he doesn't see any concern before) [1] https://meetings.opendev.org/meetings/nova/2023/nova.2023-05-23-16.01.log.ht... [2] https://docs.openstack.org/project-team-guide/stable-branches.html#end-of-li... [3] https://security.openstack.org/ossa/OSSA-2023-002.html [4] https://security.openstack.org/ossa/OSSA-2023-003.html
On 5/24/23 12:24, Sylvain Bauza wrote:
Hi folks, in particular operators...
We discussed yesterday during the nova meeting [1] about our stable branches and eventually, we were wondering whether we should EOL [2] the stable/train branch for Nova.
Why so ? Two points : 1/ The gate is failing at the moment for the branch. 2/ Two CVEs (CVE-2022-47951 [3] and CVE-2023-2088 [4]) aren't fixed in this branch.
Hi, This is very disappointing to see these CVE as the cause for deprecating the branches. It should have been the opposite way: it should have triggered some effort to fix them... :/ FYI, I tried to get the fix in, and managed to break instead of fixing. An interesting way to fix CVE-2022-47951 could be to completely disable VMDK support. How hard would this be? As for CVE-2023-2088, the issue is implementing the force
It would be difficult to fix the CVEs in the upstream branch but hopefully AFAIK all the OpenStack distros already fixed them for their related releases that use Train.
So far, I haven't seen such a fix, neither in Ubuntu or RedHat, on any version prior to ussuri. If you have a link to a working patch, please let me know. Cheers, Thomas Goirand (zigo)
On 2023-05-26 18:19:09 +0200 (+0200), Thomas Goirand wrote:
On 5/24/23 12:24, Sylvain Bauza wrote: [...] As for CVE-2023-2088, the issue is implementing the force
It would be difficult to fix the CVEs in the upstream branch but hopefully AFAIK all the OpenStack distros already fixed them for their related releases that use Train.
So far, I haven't seen such a fix, neither in Ubuntu or RedHat, on any version prior to ussuri. If you have a link to a working patch, please let me know.
I think he may be referring to Red Hat. As I understand it, they went with the https://wiki.openstack.org/wiki/OSSN/OSSN-0092 approach (mitigation through configuration only, disabling attachment-delete functionality for users). I may be wrong though, as I was not privy to their internal discussions. -- Jeremy Stanley
On Fri, 2023-05-26 at 17:10 +0000, Jeremy Stanley wrote:
On 2023-05-26 18:19:09 +0200 (+0200), Thomas Goirand wrote:
On 5/24/23 12:24, Sylvain Bauza wrote: [...] As for CVE-2023-2088, the issue is implementing the force
It would be difficult to fix the CVEs in the upstream branch but hopefully AFAIK all the OpenStack distros already fixed them for their related releases that use Train.
So far, I haven't seen such a fix, neither in Ubuntu or RedHat, on any version prior to ussuri. If you have a link to a working patch, please let me know.
for redhat openstack plathform 16 (trian) we fixed the vmdk issue (CVE-2022-47951) by increasing the version of oslo.utils? that we shiped to ensure it had the relevant json format options to inspect the iamge and bacislly used the same fix as on master. we also did that for queens / osp 13 the qemu wersion we used supprot this all the way back to 13/queens so that made that approch more viable. we cant do that upstream as it would break people but the way i would have prefered to do this would have been to simply vendor the functionality in nova and continue the backport upstream without bumping the min oslo verions. we have done that in the past for other libs.
I think he may be referring to Red Hat. As I understand it, they went with the https://wiki.openstack.org/wiki/OSSN/OSSN-0092 approach (mitigation through configuration only, disabling attachment-delete functionality for users). I may be wrong though, as I was not privy to their internal discussions.
downstream technically we never supproted VMDK in our product we did nto block it either but custoemr are not expect to use vmdk images with our downstream product. we still fixed the issue assumeing our customer cant contol what there customers are uploadign to ther openstack clouds.
participants (4)
-
Jeremy Stanley
-
Sean Mooney
-
Sylvain Bauza
-
Thomas Goirand