Rebuild phoenix and redis-commander images from source to patch SQLite

[antbob]

Both images are being rebuilt from source to patch CVE-2025-6965 — a vulnerability in the bundled SQLite library. The upstream images ship old SQLite (3.40.1 for Phoenix, 3.48.0 for Redis Commander); the fix compiles SQLite 3.50.2 from source and overlays it.

[gemini-code-assist]

Code Review

This pull request introduces custom Containerfiles for Arize Phoenix and Redis Commander to address a SQLite vulnerability (CVE-2025-6965) by building version 3.50.2 from source. It also updates the Docker Compose and OpenShift configurations to utilize these patched images and adds new build and push targets to the Makefile. Feedback identifies critical issues where redundant CMD instructions in both Containerfiles will likely cause container startup failures due to how they interact with the base images' ENTRYPOINTs. Additionally, there are concerns regarding multi-architecture support due to hardcoded library paths, a recommendation to align SQLite build flags for consistency, and a suggestion to use versioned tags instead of only 'latest' for better deployment reliability.

[gemini-code-assist]

The CMD instruction is redundant and will cause the container to fail on startup. The base image arizephoenix/phoenix already defines an ENTRYPOINT as ["python", "-m", "phoenix.server.main", "serve"]. When a CMD is provided in a child image, it is passed as arguments to the parent's ENTRYPOINT, resulting in an invalid command: python -m phoenix.server.main serve -m phoenix.server.main serve. You should remove this line to correctly inherit the parent's configuration.

[gemini-code-assist]

This CMD instruction is redundant and likely breaks the application. The upstream image uses an ENTRYPOINT that executes /redis-commander/docker/entrypoint.sh. By redefining CMD with the same path, the script path is passed as an argument to itself. The entrypoint script typically passes all arguments to the Node.js process, which will then fail to parse the script path as a valid configuration or host. Remove this line to use the inherited configuration.

[gemini-code-assist]

Hardcoding the path /usr/lib/x86_64-linux-gnu/ breaks multi-arch compatibility. On ARM64 architectures (e.g., Apple Silicon or AWS Graviton), system libraries are located in /usr/lib/aarch64-linux-gnu/. If this image is built for ARM64, the COPY will create a new directory that the system linker does not search, meaning the application will continue to use the old, vulnerable version of SQLite from the base image. This effectively bypasses the security patch on non-x86 platforms.

[gemini-code-assist]

The SQLite build configuration for Phoenix is minimal compared to the one used for redis-commander. To ensure no feature regressions (such as FTS5, RTree, or JSON support) and to optimize performance for observability workloads, it is recommended to align the build flags between the two images, including increasing the SQLITE_MAX_VARIABLE_NUMBER limit.

    CFLAGS="-O2 \
      -DSQLITE_ENABLE_FTS3_PARENTHESIS \
      -DSQLITE_ENABLE_COLUMN_METADATA \
      -DSQLITE_SECURE_DELETE \
      -DSQLITE_ENABLE_UNLOCK_NOTIFY \
      -DSQLITE_ENABLE_RTREE \
      -DSQLITE_ENABLE_GEOPOLY \
      -DSQLITE_USE_URI \
      -DSQLITE_ENABLE_DBSTAT_VTAB \
      -DSQLITE_MAX_VARIABLE_NUMBER=250000" \
    ./configure --prefix=/usr/local \
      --enable-threadsafe \
      --enable-session \
      --enable-fts3 \
      --enable-fts4 \
      --enable-fts5 && \
    make -j"$(nproc)" && \
    make install

[gemini-code-assist]

The push target only pushes the latest tag. In production environments like OpenShift, relying solely on latest can lead to non-deterministic deployments and makes rollbacks difficult. It is recommended to also tag and push images with specific version numbers or build identifiers to ensure traceability.

[antbob]

this also adds cryptography, Node.js and OpenSSL.