Current Series Release Notes

33.0.0-24

New Features

  • A new configuration option [image_format]/allowed_upload_formats controls which disk formats may be used with traditional image upload (PUT /v2/images/{id}/file). When left empty (the default), behavior is unchanged: any disk_format allowed at create time may be uploaded. When set to a non-empty list, traditional upload is rejected with HTTP 400 unless the image disk_format is in that list.

    This lets operators keep formats such as qcow2 in disk_formats so interoperable image import and the image conversion plugin can use them as the declared source format, while blocking those formats on the traditional upload path (which does not run conversion).

    Restricting who may call traditional upload remains the role of the upload_image policy. allowed_upload_formats only limits formats when configured with a non-empty list. The three related settings work independently:

    • [image_format]/disk_formats – formats allowed at image create

    • [image_format]/allowed_upload_formats – formats allowed for PUT /file

    • [image_conversion]/output_format – format stored after conversion

Upgrade Notes

  • No behavior change on upgrade. allowed_upload_formats defaults to empty, which applies no extra restriction. Operators who want the new behavior must set a non-empty list intentionally.

  • The digest_algorithm option has been removed, as it had no effect.

  • The metadata_encryption_key option and its underlying feature has been removed. It had been deprecated in the D release and was supposed to be removed in the F release.

Security Issues

  • A bug in the glance-download import method (used to copy an image from another Glance region, POST /v2/images/{image_id}/import) was fixed which allowed an unbounded amount of data to be read from the remote region’s /v2/images/{image_id}/file endpoint. A malicious or misbehaving remote region could report a small, believable size on the earlier, independent image metadata call, but then return far more data (or never terminate its response) when the file itself was fetched, keeping a task worker busy indefinitely and consuming unbounded local staging space. The download now honors the existing image_size_cap limit, aborting once more than that many bytes have been read, the same protection already applied to other image-data ingestion paths (see the web-download fix in bug 2160020). Note that the default value for this limit is 1TiB, which may be higher than is reasonable for some deployments. Operators should take this opportunity to review that setting for correctness.

  • Also fixed a related bug in the glance-download import flow’s failure handling: if the download step failed after the image metadata step had already run, reverting the flow could raise an unrelated InvalidImageStatusTransition error (attempting to move the image from queued to queued), which masked the real failure reason in the task record. The image now reverts to queued cleanly regardless of ordering.

  • A bug in the location_import flow used by POST /v2/images/{image_id}/locations was fixed which allowed the background secure-hash calculation (do_secure_hash, enabled by default) to read an unbounded amount of data from the image location. A malicious or misbehaving remote location could report a small, believable size when the location was validated, but then return far more data (or never terminate its response) when the data was actually fetched for hashing, keeping a task worker busy indefinitely. Hash calculation now honors the existing image_size_cap limit, aborting once more than that many bytes have been read, the same protection already applied to other image-data ingestion paths (see the web-download fix in bug 2160020). Note that the default value for this limit is 1TiB, which may be higher than is reasonable for some deployments. Operators should take this opportunity to review that setting for correctness.

33.0.0

Bug Fixes

  • Fix a regression introduced when fixing CVE-2026-71197. Now during image import via web-download, if the image host is resolved to several IP addresses by DNS, all of them that pass filtering critera will be tried one by one.

    This among others ensures that if DNS resolves to both IPv4 and IPv6 addresses but Glance itself is running in a single stack network, the correct IP address that Glance can connect to will eventually be tried.