update python3.12 packages with security fixes in the CSI container image

[BarthV]

Disclaimer : I know this is not the recommended change request proposal. Feel free to copy/duplicate the change and include that into your own workflow. So treat that more as an example/proposal.

Thanks a lot !

update python3.12 packages with security fixes in the CSI container image

Summary

The published vastdataorg/csi images (2.6.5-hf4, 2.6.5-hf6, and any build using the current date-pinned base) ship python3.12-devel 3.12.12-4.el9_7.3, which is vulnerable to a few CVE (like CVE-2025-59375 that has been flagged by our internal system).

This PR updates the affected Python packages during the per-release image build so every published tag picks up the patched RPM.

Root cause

The image is built in two stages:

• packaging/base.Dockerfile → a date-pinned base image (vast-csi-base:<date>), rebuilt manually via the build_csi_base CI job. This is where python3.12-devel is installed.
• packaging/Dockerfile → layers the application code on top, built on every release.

base.Dockerfile already lists python3.12-devel in a microdnf update, but because the base is date-pinned and only rebuilt occasionally, released images never pick up newer patched RPMs.
The fix therefore belongs in packaging/Dockerfile, which runs on every release.

Change

add the following lines to packaging/base.Dockerfile (after RUN microdnf update -y ... block ~L34 ) :

# Pull the latest security fixes for the Python packages on top of the (date-pinned) base image
# microdnf is shipped by ubi9-minimal not by yum/dnf
RUN microdnf update -y python3.12 python3.12-libs python3.12-devel \
    && microdnf clean all

python3.12, python3.12-libs, and python3.12-devel all derive from the same python3.12 source RPM, so all three are updated together. The base image is ubi9-minimal, which natively provides microdnf (not yum/dnf).

Testing

Built and verified locally (podman, x86_64). Because the production base image is private, the real packaging/Dockerfile (with this change) was built on top of [registry.access.redhat.com/ubi9/python-312:9.7](http://registry.access.redhat.com/ubi9/python-312:9.7), which ships the exact flagged version 3.12.12-4.el9_7.3.

So, all three packages from the affected source RPM are upgraded:

Package	Before	After
python3.12	3.12.12-4.el9_7.3	3.12.13-3.el9_8
python3.12-libs	3.12.12-4.el9_7.3	3.12.13-3.el9_8
python3.12-devel	3.12.12-4.el9_7.3	3.12.13-3.el9_8

Authoritative rpm version comparison:

• rpm.vercmp("3.12.13-3.el9_8", "3.12.13-2.el9_8") : 1 (installed ≥ fix) → remediated
• rpm.vercmp("3.12.12-4.el9_7.3", "3.12.13-2.el9_8") : -1 (confirms the original vulnerable state)

Notes

• Generic remediation RUN yum update python3.12-devel does not apply here: ubi9-minimal has microdnf only, so the command must use microdnf.
• Optional follow-up: python3.12-devel, gcc, g++, and make are build-only dependencies (the build already strips the GCC cc1* binaries). Removing python3.12-devel after poetry install would eliminate a whole class of CVE from the runtime image, at the cost of a larger change.