Bug#992330: bullseye-pu: package nova/22.2.2-1+deb11u1 (CVE-2021-3654)
Hi Thomas,
[not an authoritative answer, but a suggestion below]
On Tue, Aug 17, 2021 at 12:57:50PM +0200, Thomas Goirand wrote:
> Package: release.debian.org
> Severity: normal
> Tags: buster
> User: release.debian.org@packages.debian.org
> Usertags: pu
>
> (Please provide enough information to help the release team
> to judge the request efficiently. E.g. by filling in the
> sections below.)
>
> [ Reason ]
> Nova contains an open redirect on the VNC console URL, where
> the URL:
> https://vnc-console-host.com//example.com/scam-url.html
>
> would redirect to http://example.com/scam-url.html.
>
> Of course, that's not a big issue (which is why there's no DSA),
> but I would still like to get this fixed in Bullseye.
>
> 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
>
> I'm especially interested having this bug solved:
>
> "The libvirt virt driver will no longer attempt to fetch volume
> encryption metadata or the associated secret key when attaching
> LUKSv1 encrypted volumes if a libvirt secret already exists on
> the host.
> This resolves bug 1905701 (https://launchpad.net/bugs/1905701)
> where instances with LUKSv1 encrypted volumes could not be
> restarted automatically by the nova-compute service after a host
> reboot when the [DEFAULT]/resume_guests_state_on_host_boot
> configurable was enabled."
>
> but the other issue (ie: Improved detection of anti-affinity
> policy violation when performing live and cold migrations.) is
> also very nice to have.
>
> Also, I've upgraded all of my live clusters (including a public
> cloud) to this version of Nova, and I would like to keep
> Bullseye in sync with what I am maintaining.
>
> [ Impact ]
> Open redirect in the VNC console could be use by spammers to
> hide the real URLs.
>
> [ Tests ]
> Not only upstream runs a battery of unit and functional tests,
> but the Nova package itself runs 16946 unit tests at build time.
> Also, we're using version 22.2.2-1 of Nova in production, and
> our deployment suffer no regression.
>
> [ Risks ]
> No risk during upgrade that I know of.
>
> [ Checklist ]
> [x] *all* changes are documented in the d/changelog
> [x] I reviewed all changes and I approve them
> [ ] attach debdiff against the package in (old)stable
> [x] the issue is verified as fixed in unstable
>
> The debdiff being too big, please find it, together with the
> built packages, at:
> http://shade.infomaniak.ch/bullseye-pu/nova/
>
> [ Changes ]
> Here's the details of the debian/changelog explained.
>
> * 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...
>
> * New upstream release.
>
> See above.
>
> * 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).
>
> Please allow me to upload nova/22.2.2-1+deb11u1 to Bullseye,
> Cheers,
If this is an import of a new upstream version on top of the current
packaging (plus some adjustment) then please actually use
2:22.2.2-0+deb11u1 which sorts before (an immaginary present)
2:22.2.2-1 at some point in unstable.
Alternatively 2:22.2.2-1~deb11u1.
Regards,
Salvatore
Reply to: