Bug#992330: bullseye-pu: package nova/22.2.2-1+deb11u1 (CVE-2021-3654)
Hi Julien,
Thanks for your (unfortunately late) answer.
On 12/3/21 3:11 PM, Julien Cristau wrote:
> Control: tag -1 moreinfo
>
> Hi Thomas,
>
> On Tue, Aug 17, 2021 at 12:57:50PM +0200, Thomas Goirand wrote:
>> Also, I would like to get Nova upgraded to the latest point
>> release, to fix numerous small issues. The release notes for
>> Nova are there:
>>
>> https://docs.openstack.org/releasenotes/nova/victoria.html
>>
> That looks incomplete? Please include a complete description of the
> changes you want approved.
What do you need exactly that isn't available publicly? The full commit
history for Nova Victoria stable branch is here:
https://opendev.org/openstack/nova/commits/branch/stable/victoria
Here are the commits sum-ups:
Changes in nova 22.2.0..22.2.1
------------------------------
210abc09b8 guestfs: With libguestfs >= v1.41.1 decode returned bytes to
string
7b4f479647 Dynamically archive FK related records in archive_deleted_rows
21241b38dd Add functional test for bug 1837995
382d64ea36 Centralize sqlite FK constraint enforcement
c7d9d6d9dd Fix the vGPU dynamic options race
276b8db5af Add config parameter 'live_migration_scheme' to live
migration with tls guide
5d1adb2604 libvirt: Use specific user when probing encrypted rbd disks
during extend
3d84097eab api: Log os-resetState as an instance action
831abc9f83 Use absolute path during qemu img rebase
eda11a4875 libvirt: Skip encryption metadata lookups if secret already
exists on host
Changes in nova 22.1.0..22.2.0
------------------------------
35112d7667 Handle instance = None in _local_delete_cleanup
4f17ea2f7d Add regression test for bug 1914777
3d86df068a tools: Allow check-cherry-picks.sh to be disabled by an env var
ef348c4eb3 only wait for plugtime events in pre-live-migration
8e12b81839 Disallow CONF.compute.max_disk_devices_to_attach = 0
09784db62f Prevent archiving of pci_devices records because of
'instance_uuid'
Changes in nova 22.0.1..22.1.0
------------------------------
eebf94b654 compute: Lock by instance.uuid lock during swap_volume
63d2e62c3a Use subqueryload() instead of joinedload() for (system_)metadata
6b57575092 Fallback to same-cell resize with qos ports
7366e3c375 Reproduce bug 1907522 in functional test
4e5b92545d Add upgrade check about old computes
0c5ca351e2 Warn when starting services with older than N-1 computes
e3da2ca7be lower-constraints: Bump packaging to 20.4
c3a0969329 Omit resource inventories from placement update if zero
eda458828b compute: Don't detach volumes when RescheduledException
raised without retry
95fc161334 Add regression test for bug #1899649
478be6f4fb zuul: Replace nova-live-migration with zuulv3 jobs
f4d62e1a0b Fix a hacking test
82d415d200 Add missing exception
3ecc098d28 Set instance host and drop migration under lock
d768cdbb88 Reproduce bug 1896463 in func env
9a5b6249d6 Use cell targeted context to query BDMs for metadata
Do you insist on reviewing *ALL* of the commits, one by one? As you can
read above, *all* is bugfix only.
Why don't you trust upstream bugfix releases, which contains only
targeted bugfixes only, and that goes through extensive unit and
functional testing? I also tested the point release, and I have it in
production... Products like Firefox ESR get updated this way, and it
doesn't seem to be a problem. Should OpenStack be treated differently?
If so, why?
>> [ Risks ]
>> No risk during upgrade that I know of.
>>
> That is.. not reassuring.
What do you need to re reassured?
>> * Tune nova-api-{,metadata-}uwsgi.ini for performance.
>>
>> This is a minor tweak to the uwsgi.ini default configuration,
>> which I've started pushing on all OpenStack packages in Debian.
>> It's only better with it...
>
> I don't think this is appropriate for stable. There's no information on
> what environment(s) this is tuned for, or benchmarked in.
This simply increases the number of processes.
https://salsa.debian.org/openstack-team/services/nova/-/commit/46a908d772c542eb63d9013ee71d70f820f32e4e
Note that right now, the number of threads is back to "1" (in a later
commit) because otherwise nova-api fails to work properly in some cases,
because of Eventlet threading thing.
The number of process set to 8 is only a better default because without
it, uwsgi starts with the same amount of process as core. With modern
servers, that's a way too much (imagine 32 processes on a 64 core
machine...) and may eat-up too much memory.
What's also very important is the "listen 100" which is comparable to
the same kind of directive in Apache (ie: to accept maximum 100 waiting
connections). Our bench (which I do not have handy, sorry) showed it
helps a lot with performances (approximately x2 faster).
>> * New upstream release.
>>
>> See above.
>
> I'll reserve my opinion on that until we have a better description of
> the changes. It seems plausible, broadly.
>
>> * CVE-2021-3654: novnc allows open redirection. Added upstream patch:
>> Reject_open_redirection_in_the_console_proxy.patch (Closes: #991441).
>>
>> This addresses the main issue that mandates the pu.
>>
>> * Do not maintain glance_api_servers through debconf (as the default of
>> reading its URL in the Keystone catalogue is better).
>>
>> This avoids tweaking nova.conf on upgrades, which could otherwise
>> potentially destroy one's deployment. Indeed, one very valid (and in
>> fact recommended) way to deploy, is to *NOT* set the glance_api_servers
>> directive. With the debconf code, this forces having something. After
>> removing the debconf integration for this directive, upgrade to the
>> proposed update isn't breaking deployments anymore, while leaving already
>> configured glance_api_servers alone (so not destroying anyone setup).
>>
> Shouldn't nova/glance_api_servers be cleaned up from the debconf
> database if it's no longer used? I'm also not convinced this is
> appropriate for stable.
This is appropriate because what was there actually *BREAKS* an
otherwise working setup: the Glance endpoint is just read from the
Keystone service catalogue, and what's done by the debconf thingy, is
uncommenting the directive. So upgrading without this change can
actually break a cluster. I can add the code to clean-up the debconf
database if you think that is better.
Cheers,
Thomas Goirand (zigo)
Reply to: