-
Notifications
You must be signed in to change notification settings - Fork 113
RHAIENG-987: remove skopeo
and OpenShift client installation from RStudio Dockerfiles to address CVE-2025-4674
#2384
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RHAIENG-987: remove skopeo
and OpenShift client installation from RStudio Dockerfiles to address CVE-2025-4674
#2384
Conversation
WalkthroughRemoved skopeo and the OpenShift Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Pre-merge checks (2 passed, 1 warning)❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
📜 Recent review detailsConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro 📒 Files selected for processing (6)
🚧 Files skipped from review as they are similar to previous changes (6)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)
✨ Finishing touches
🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
/cc @keklundrh |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (4)
rstudio/c9s-python-3.11/Dockerfile.cuda (1)
28-29
: Use onlydnf clean all -y
; drop manual cache rm.-RUN dnf install -y mesa-libGL && dnf clean all && rm -rf /var/cache/yum +RUN dnf install -y mesa-libGL && dnf clean all -yrstudio/c9s-python-3.11/Dockerfile.cpu (1)
26-27
: Align cleanup with repo guidance (dnf clean all -y
only).-RUN dnf install -y mesa-libGL && dnf clean all && rm -rf /var/cache/yum +RUN dnf install -y mesa-libGL && dnf clean all -yrstudio/rhel9-python-3.11/Dockerfile.cpu (1)
21-22
: Preferdnf clean all -y
withoutrm -rf
.-RUN dnf install -y mesa-libGL && dnf clean all && rm -rf /var/cache/yum +RUN dnf install -y mesa-libGL && dnf clean all -yscripts/dockerfile_fragments.py (1)
39-49
: Harden oc install snippet (checksum + arch mapping) when applied to non-RStudio files.The inserted block still lacks checksum verification and will break on ARM due to
aarch64
vsarm64
. Consider updating the injected snippet accordingly (keeps current behavior but safer).Apply:
- blockinfile( - dockerfile, - textwrap.dedent(r""" - RUN curl -L https://mirror.openshift.com/pub/openshift-v4/$(uname -m)/clients/ocp/stable/openshift-client-linux.tar.gz \ - -o /tmp/openshift-client-linux.tar.gz && \ - tar -xzvf /tmp/openshift-client-linux.tar.gz oc && \ - rm -f /tmp/openshift-client-linux.tar.gz - """), - prefix="Install the oc client", - ) + blockinfile( + dockerfile, + textwrap.dedent(r""" + RUN set -eux; \ + arch="$(uname -m)"; \ + case "$arch" in \ + aarch64) arch=arm64 ;; \ + x86_64|ppc64le|s390x) ;; \ + *) echo "Unsupported arch: $arch" >&2; exit 1 ;; \ + esac; \ + curl -fsSL "https://mirror.openshift.com/pub/openshift-v4/${arch}/clients/ocp/stable/sha256sum.txt" -o /tmp/oc.sha256 && \ + curl -fsSL "https://mirror.openshift.com/pub/openshift-v4/${arch}/clients/ocp/stable/openshift-client-linux.tar.gz" -o /tmp/openshift-client-linux.tar.gz && \ + grep 'openshift-client-linux.tar.gz' /tmp/oc.sha256 | sha256sum -c - && \ + tar -xzvf /tmp/openshift-client-linux.tar.gz oc && \ + rm -f /tmp/openshift-client-linux.tar.gz /tmp/oc.sha256 + """), + prefix="Install the oc client", + )
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
rstudio/c9s-python-3.11/Dockerfile.cpu
(1 hunks)rstudio/c9s-python-3.11/Dockerfile.cuda
(1 hunks)rstudio/rhel9-python-3.11/Dockerfile.cpu
(1 hunks)rstudio/rhel9-python-3.11/Dockerfile.cuda
(1 hunks)scripts/dockerfile_fragments.py
(2 hunks)
🧰 Additional context used
🧠 Learnings (18)
📓 Common learnings
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: jupyter/pytorch/ubi9-python-3.12/Dockerfile.cuda:42-52
Timestamp: 2025-07-09T12:29:56.162Z
Learning: jiridanek requested GitHub issue creation for OpenShift client architecture mapping problem affecting 29 Dockerfiles during PR #1320 review. Issue was created with comprehensive analysis covering all affected files using $(uname -m) returning 'aarch64' but OpenShift mirror expecting 'arm64', systematic solution using BuildKit TARGETARCH mapping with proper amd64→x86_64 and arm64→arm64 conversion, detailed acceptance criteria, and implementation guidance, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2000
File: runtimes/tensorflow/ubi9-python-3.11/Pipfile:41-41
Timestamp: 2025-08-20T12:19:34.523Z
Learning: jiridanek created GitHub issue #2055 to track the remaining runtimes/rocm-tensorflow/ubi9-python-3.12/Pipfile.lock file that stayed at jupyter-core==5.7.2 during PR #2000, ensuring systematic follow-up for complete CVE-2025-30167 remediation across all runtime images in the opendatahub-io/notebooks repository.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1909
File: runtimes/pytorch+llmcompressor/ubi9-python-3.11/Dockerfile.cuda:11-15
Timestamp: 2025-08-12T08:40:55.286Z
Learning: jiridanek requested GitHub issue creation for redundant CUDA upgrade optimization during PR #1909 review. Analysis revealed all 14 CUDA Dockerfiles contain redundant `yum upgrade -y` commands in cuda-base stages that execute after base stages already performed comprehensive `dnf upgrade` via pre-upgrade blocks, causing unnecessary CI latency and build inefficiency. Issue includes complete scope analysis with specific line numbers, investigation framework requiring NVIDIA upstream documentation review, multiple solution options, comprehensive acceptance criteria covering systematic testing and performance measurement, and proper context linking to PR #1909 review comment.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-08-27T18:54:33.532Z
Learning: jiridanek requested GitHub issue creation for comment typo fix during PR #2145 review, specifically fixing "hhttps" to "https" in rstudio/rhel9-python-3.11/Dockerfile.cuda line 139 NVIDIA CUDA Dockerfile reference. Issue #2164 was created with comprehensive problem description, clear before/after solution, and acceptance criteria, continuing the established pattern of systematic code quality improvements through detailed issue tracking for even minor documentation fixes.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1306
File: jupyter/trustyai/ubi9-python-3.12/Dockerfile.cpu:4-4
Timestamp: 2025-07-04T05:49:10.314Z
Learning: jiridanek directs base image pinning security concerns to existing comprehensive issue #1242 "Improve Docker FROM image versioning by avoiding :latest tags" rather than addressing them in individual PRs, continuing the established pattern of systematic security and quality tracking in opendatahub-io/notebooks.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-11T11:16:05.131Z
Learning: jiridanek requested GitHub issue creation for RStudio py311 Tekton push pipelines during PR #1379 review. Issue #1384 was successfully created covering two RStudio variants (CPU and CUDA) found in manifests/base/params-latest.env, with comprehensive problem description, implementation requirements following the same pattern as other workbench pipelines, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2215
File: runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu:0-0
Timestamp: 2025-09-05T11:27:31.040Z
Learning: jiridanek requested GitHub issue creation for build toolchain optimization in datascience runtime during PR #2215 review. Issue #2308 was created addressing unnecessary build dependencies (gcc-toolset-13, cmake, ninja-build, rust, cargo) in final runtime image for ppc64le architecture, covering comprehensive problem analysis with specific line numbers, multiple solution options for builder-only toolchains, clear acceptance criteria for size reduction and security improvement, detailed implementation guidance for package segregation, and proper context linking to PR #2215 review comment, continuing the established pattern of systematic infrastructure improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/minimal/ubi9-python-3.12/requirements.txt:289-292
Timestamp: 2025-07-08T19:52:16.010Z
Learning: jiridanek requested GitHub issue creation for jupyter-core security upgrade to address CVE-2025-30167 during PR #1333 review. Issue #1351 was created with comprehensive security vulnerability description covering high-severity privilege escalation on Windows, affected files analysis, specific upgrade instructions from version 5.7.2 to 5.8.1+, detailed acceptance criteria for security verification and repository audit, phased implementation guidance, and proper context linking, continuing the established pattern of systematic security improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1909
File: runtimes/pytorch+llmcompressor/ubi9-python-3.11/Dockerfile.cuda:11-15
Timestamp: 2025-08-12T08:40:55.286Z
Learning: jiridanek requested GitHub issue creation for redundant CUDA upgrade optimization during PR #1909 review. Issue covers duplicate yum/dnf upgrade commands in cuda-base stages that execute after base stages already performed comprehensive upgrades, causing unnecessary CI latency and build inefficiency across multiple CUDA Dockerfiles. The solution requires investigating NVIDIA upstream documentation requirements before removing redundant upgrades, with systematic testing of all CUDA variants and performance measurement. Issue follows established pattern of comprehensive problem analysis, multiple solution options, detailed acceptance criteria, and proper context linking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2367
File: .github/workflows/build-notebooks-pr-aipcc.yaml:68-79
Timestamp: 2025-09-09T18:48:54.058Z
Learning: jiridanek requested GitHub issue creation for pull_request_target workflow security hardening during PR #2367 review, specifically addressing the direct usage of github.event.pull_request.head.ref (untrusted branch names) in shell scripts within .github/workflows/build-notebooks-pr-aipcc.yaml. Issue was created with comprehensive security analysis covering low-medium risk assessment with existing permission check mitigation, detailed solution approach using environment variables and safe ref handling, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic security improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/Dockerfile.rocm:34-37
Timestamp: 2025-07-02T18:19:23.024Z
Learning: In the opendatahub-io/notebooks repository, issue #1241 "Security: Add checksum verification for downloaded binaries in Python 3.12 images" covers the security concern about verifying downloaded binaries including the oc client. Red Hat does not provide signed RPM packages for the OpenShift CLI (oc) in UBI9 official repositories, making manual binary download with checksum verification the recommended approach.
Learnt from: grdryn
PR: opendatahub-io/notebooks#1320
File: rstudio/rhel9-python-3.11/Dockerfile.cuda:34-35
Timestamp: 2025-07-04T10:41:13.061Z
Learning: In the opendatahub-io/notebooks repository, when adapting NVIDIA CUDA Dockerfiles, the project intentionally maintains consistency with upstream NVIDIA patterns even when it might involve potential risks like empty variable expansions in package installation commands. This is considered acceptable because the containers only run on RHEL 9 with known yum/dnf behavior, and upstream consistency is prioritized over defensive coding practices.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2114
File: Makefile:22-24
Timestamp: 2025-08-27T07:37:13.713Z
Learning: In the opendatahub-io/notebooks repository, when transitioning from Python 3.11 to 3.12 as the default RELEASE_PYTHON_VERSION, RStudio images (both c9s and rhel9 variants) should retain Python 3.11 support, requiring the piplock-renewal.yaml workflow matrix to include both Python versions ["3.11", "3.12"].
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1760
File: jupyter/pytorch+llmcompressor/ubi9-python-3.11/Dockerfile.cuda:241-244
Timestamp: 2025-08-08T08:38:32.988Z
Learning: Policy: In opendatahub-io/notebooks, do not remove micropipenv from Python 3.11 images to avoid breaking existing users. Cleanups can deduplicate duplicate installs and remove unused uv, but micropipenv must remain present in 3.11 images.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1720
File: jupyter/tensorflow/ubi9-python-3.12/requirements.txt:1531-1558
Timestamp: 2025-08-07T12:39:01.997Z
Learning: In opendatahub-io/notebooks, the ROCm TensorFlow Python 3.12 UBI9 image (runtimes/rocm-tensorflow/ubi9-python-3.12/Dockerfile.rocm) was missing libxcrypt-compat, which is required for MySQL SASL2 plugin authentication with mysql-connector-python==9.3.0 on Python 3.12 UBI9. Issue #1722 was created to track this, following the established pattern for systematic dependency consistency and runtime compatibility across all Python 3.12 UBI9 images.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#968
File: runtimes/rocm-tensorflow/ubi9-python-3.12/Dockerfile.rocm:17-18
Timestamp: 2025-08-06T15:33:47.175Z
Learning: During PR #968 review, CodeRabbit initially incorrectly identified 1 legitimate micropipenv usage in jupyter/tensorflow/ubi9-python-3.12/Dockerfile.cuda when analyzing Python 3.12 images for unused dependencies. Upon jiridanek's request for re-verification, comprehensive analysis revealed all 15 Python 3.12 Dockerfiles install micropipenv but none actually use it, making the cleanup scope 100% unnecessary installations with no exceptions to handle.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1909
File: runtimes/pytorch/ubi9-python-3.11/Dockerfile.cuda:11-15
Timestamp: 2025-08-12T08:37:52.783Z
Learning: In opendatahub-io/notebooks repository Dockerfiles, when cleaning DNF cache after package operations, use only `dnf clean all -y` rather than adding `rm -rf /var/cache/dnf`. The `dnf clean all` command is sufficient and safer as it uses the package manager itself to intelligently remove cached data (downloaded packages, repository metadata, expired transaction info) without bypassing DNF's internal workings. Adding `rm -rf /var/cache/dnf` is redundant and potentially less safe for future DNF compatibility.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2185
File: jupyter/pytorch/ubi9-python-3.12/Dockerfile.cuda:109-117
Timestamp: 2025-08-29T08:48:55.985Z
Learning: jiridanek prefers to implement systematic cleanup improvements through dedicated GitHub issues (like #2076) rather than applying individual point fixes during PR reviews, maintaining consistency with their established pattern of comprehensive code quality improvements.
📚 Learning: 2025-07-04T10:41:13.061Z
Learnt from: grdryn
PR: opendatahub-io/notebooks#1320
File: rstudio/rhel9-python-3.11/Dockerfile.cuda:34-35
Timestamp: 2025-07-04T10:41:13.061Z
Learning: In the opendatahub-io/notebooks repository, when adapting NVIDIA CUDA Dockerfiles, the project intentionally maintains consistency with upstream NVIDIA patterns even when it might involve potential risks like empty variable expansions in package installation commands. This is considered acceptable because the containers only run on RHEL 9 with known yum/dnf behavior, and upstream consistency is prioritized over defensive coding practices.
Applied to files:
rstudio/c9s-python-3.11/Dockerfile.cpu
rstudio/rhel9-python-3.11/Dockerfile.cpu
rstudio/rhel9-python-3.11/Dockerfile.cuda
rstudio/c9s-python-3.11/Dockerfile.cuda
📚 Learning: 2025-09-05T12:25:09.719Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2227
File: codeserver/ubi9-python-3.12/Dockerfile.cpu:122-123
Timestamp: 2025-09-05T12:25:09.719Z
Learning: jiridanek requested GitHub issue creation for Docker multi-stage synchronization improvement in codeserver/ubi9-python-3.12/Dockerfile.cpu during PR #2227 review. The issue addresses sentinel file pattern using /tmp/control copied to /dev/null for stage coordination between rpm-base, whl-cache, and codeserver stages, proposing semantic improvements with descriptive file names, inline documentation, and elimination of /dev/null hack while maintaining multi-architecture build functionality for ppc64le support.
Applied to files:
rstudio/c9s-python-3.11/Dockerfile.cpu
rstudio/rhel9-python-3.11/Dockerfile.cpu
📚 Learning: 2025-08-07T12:39:01.997Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1720
File: jupyter/tensorflow/ubi9-python-3.12/requirements.txt:1531-1558
Timestamp: 2025-08-07T12:39:01.997Z
Learning: In opendatahub-io/notebooks, the ROCm TensorFlow Python 3.12 UBI9 image (runtimes/rocm-tensorflow/ubi9-python-3.12/Dockerfile.rocm) was missing libxcrypt-compat, which is required for MySQL SASL2 plugin authentication with mysql-connector-python==9.3.0 on Python 3.12 UBI9. Issue #1722 was created to track this, following the established pattern for systematic dependency consistency and runtime compatibility across all Python 3.12 UBI9 images.
Applied to files:
rstudio/c9s-python-3.11/Dockerfile.cpu
rstudio/rhel9-python-3.11/Dockerfile.cuda
📚 Learning: 2025-08-06T15:22:17.997Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#968
File: runtimes/rocm-tensorflow/ubi9-python-3.12/Dockerfile.rocm:17-18
Timestamp: 2025-08-06T15:22:17.997Z
Learning: jiridanek requested GitHub issue creation for micropipenv removal from Python 3.12 images during PR #968 review. Analysis revealed 15 affected Dockerfiles with only 1 legitimate usage (jupyter/tensorflow/ubi9-python-3.12/Dockerfile.cuda using micropipenv install --dev) while 14 images install micropipenv unnecessarily. Issue #1685 was created with comprehensive problem description covering ~238MB total waste across unused installations, detailed scope analysis, multiple solution options, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Applied to files:
rstudio/c9s-python-3.11/Dockerfile.cpu
📚 Learning: 2025-08-06T15:33:47.175Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#968
File: runtimes/rocm-tensorflow/ubi9-python-3.12/Dockerfile.rocm:17-18
Timestamp: 2025-08-06T15:33:47.175Z
Learning: During PR #968 review, CodeRabbit initially incorrectly identified 1 legitimate micropipenv usage in jupyter/tensorflow/ubi9-python-3.12/Dockerfile.cuda when analyzing Python 3.12 images for unused dependencies. Upon jiridanek's request for re-verification, comprehensive analysis revealed all 15 Python 3.12 Dockerfiles install micropipenv but none actually use it, making the cleanup scope 100% unnecessary installations with no exceptions to handle.
Applied to files:
rstudio/c9s-python-3.11/Dockerfile.cpu
rstudio/rhel9-python-3.11/Dockerfile.cuda
📚 Learning: 2025-08-08T08:38:32.988Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1760
File: jupyter/pytorch+llmcompressor/ubi9-python-3.11/Dockerfile.cuda:241-244
Timestamp: 2025-08-08T08:38:32.988Z
Learning: Policy: In opendatahub-io/notebooks, do not remove micropipenv from Python 3.11 images to avoid breaking existing users. Cleanups can deduplicate duplicate installs and remove unused uv, but micropipenv must remain present in 3.11 images.
Applied to files:
rstudio/c9s-python-3.11/Dockerfile.cpu
📚 Learning: 2025-08-12T08:40:55.286Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1909
File: runtimes/pytorch+llmcompressor/ubi9-python-3.11/Dockerfile.cuda:11-15
Timestamp: 2025-08-12T08:40:55.286Z
Learning: jiridanek requested GitHub issue creation for redundant CUDA upgrade optimization during PR #1909 review. Analysis revealed all 14 CUDA Dockerfiles contain redundant `yum upgrade -y` commands in cuda-base stages that execute after base stages already performed comprehensive `dnf upgrade` via pre-upgrade blocks, causing unnecessary CI latency and build inefficiency. Issue includes complete scope analysis with specific line numbers, investigation framework requiring NVIDIA upstream documentation review, multiple solution options, comprehensive acceptance criteria covering systematic testing and performance measurement, and proper context linking to PR #1909 review comment.
Applied to files:
rstudio/c9s-python-3.11/Dockerfile.cpu
rstudio/rhel9-python-3.11/Dockerfile.cpu
rstudio/rhel9-python-3.11/Dockerfile.cuda
rstudio/c9s-python-3.11/Dockerfile.cuda
📚 Learning: 2025-09-05T12:10:50.856Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2215
File: runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu:0-0
Timestamp: 2025-09-05T12:10:50.856Z
Learning: jiridanek requested GitHub issue creation for Dockerfile environment variable refactoring during PR #2215 review. Issue #2311 was created addressing build-only variables (OPENBLAS_VERSION, ONNX_VERSION, GRPC_PYTHON_BUILD_SYSTEM_OPENSSL) being unnecessarily written to /etc/profile.d/ppc64le.sh in runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu, causing variable duplication across stages, unreliable sourcing in non-login build contexts, and violation of DRY principles. The issue includes comprehensive problem description covering affected lines 30-37, detailed impact analysis of build reliability and maintenance overhead, three solution options with centralized ARG/ENV approach as recommended, clear acceptance criteria for version centralization and build-only variable cleanup, and specific implementation guidance with code examples, assigned to jiridanek, continuing the established pattern of systematic infrastructure improvements through detailed issue tracking.
Applied to files:
rstudio/c9s-python-3.11/Dockerfile.cpu
rstudio/rhel9-python-3.11/Dockerfile.cpu
rstudio/rhel9-python-3.11/Dockerfile.cuda
rstudio/c9s-python-3.11/Dockerfile.cuda
📚 Learning: 2025-07-02T18:19:23.024Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/Dockerfile.rocm:34-37
Timestamp: 2025-07-02T18:19:23.024Z
Learning: In the opendatahub-io/notebooks repository, issue #1241 "Security: Add checksum verification for downloaded binaries in Python 3.12 images" covers the security concern about verifying downloaded binaries including the oc client. Red Hat does not provide signed RPM packages for the OpenShift CLI (oc) in UBI9 official repositories, making manual binary download with checksum verification the recommended approach.
Applied to files:
rstudio/c9s-python-3.11/Dockerfile.cpu
rstudio/rhel9-python-3.11/Dockerfile.cpu
rstudio/rhel9-python-3.11/Dockerfile.cuda
rstudio/c9s-python-3.11/Dockerfile.cuda
📚 Learning: 2025-08-27T18:54:33.532Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-08-27T18:54:33.532Z
Learning: jiridanek requested GitHub issue creation for comment typo fix during PR #2145 review, specifically fixing "hhttps" to "https" in rstudio/rhel9-python-3.11/Dockerfile.cuda line 139 NVIDIA CUDA Dockerfile reference. Issue #2164 was created with comprehensive problem description, clear before/after solution, and acceptance criteria, continuing the established pattern of systematic code quality improvements through detailed issue tracking for even minor documentation fixes.
Applied to files:
rstudio/rhel9-python-3.11/Dockerfile.cpu
rstudio/rhel9-python-3.11/Dockerfile.cuda
rstudio/c9s-python-3.11/Dockerfile.cuda
📚 Learning: 2025-09-05T12:10:50.856Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2215
File: runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu:0-0
Timestamp: 2025-09-05T12:10:50.856Z
Learning: jiridanek requested GitHub issue creation for Dockerfile environment variable refactoring during PR #2215 review. Issue addresses build-only variables (OPENBLAS_VERSION, ONNX_VERSION, GRPC_PYTHON_BUILD_SYSTEM_OPENSSL) being unnecessarily written to /etc/profile.d/ppc64le.sh in runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu, causing variable duplication across stages, unreliable sourcing in non-login build contexts, and violation of DRY principles. The issue includes comprehensive problem description covering affected lines 30-37, detailed impact analysis of build reliability and maintenance overhead, three solution options with centralized ARG/ENV approach as recommended, clear acceptance criteria for version centralization and build-only variable cleanup, and specific implementation guidance with code examples, continuing the established pattern of systematic infrastructure improvements through detailed issue tracking.
Applied to files:
rstudio/rhel9-python-3.11/Dockerfile.cpu
📚 Learning: 2025-08-27T18:58:27.554Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-08-27T18:58:27.554Z
Learning: jiridanek requested GitHub issue creation for URL typo fix during PR #2145 review, identifying "hhttps" instead of "https" in rstudio/rhel9-python-3.11/Dockerfile.cuda line 139. Issue #2166 was created with specific line reference, before/after diff, and acceptance criteria for this minor but important documentation accuracy fix, demonstrating attention to detail in code review process.
Applied to files:
rstudio/rhel9-python-3.11/Dockerfile.cpu
rstudio/rhel9-python-3.11/Dockerfile.cuda
rstudio/c9s-python-3.11/Dockerfile.cuda
📚 Learning: 2025-08-12T08:40:55.286Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1909
File: runtimes/pytorch+llmcompressor/ubi9-python-3.11/Dockerfile.cuda:11-15
Timestamp: 2025-08-12T08:40:55.286Z
Learning: jiridanek requested GitHub issue creation for redundant CUDA upgrade optimization during PR #1909 review. Issue covers duplicate yum/dnf upgrade commands in cuda-base stages that execute after base stages already performed comprehensive upgrades, causing unnecessary CI latency and build inefficiency across multiple CUDA Dockerfiles. The solution requires investigating NVIDIA upstream documentation requirements before removing redundant upgrades, with systematic testing of all CUDA variants and performance measurement. Issue follows established pattern of comprehensive problem analysis, multiple solution options, detailed acceptance criteria, and proper context linking.
Applied to files:
rstudio/rhel9-python-3.11/Dockerfile.cuda
rstudio/c9s-python-3.11/Dockerfile.cuda
📚 Learning: 2025-08-27T19:00:57.755Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-08-27T19:00:57.755Z
Learning: jiridanek requested GitHub issue creation for tensorflow[and-cuda] extra removal investigation during PR #2145 review, addressing the concern that this extra forces CUDA-specific wheels causing cross-platform conflicts while Docker images already supply CUDA via base layer. Issue #2168 was created with comprehensive investigation framework covering dependency differences, runtime verification, performance testing, cross-platform compatibility, and clear acceptance criteria for deciding whether to remove the extra in favor of base tensorflow package.
Applied to files:
rstudio/c9s-python-3.11/Dockerfile.cuda
📚 Learning: 2025-08-27T14:49:24.112Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2145
File: runtimes/pytorch+llmcompressor/ubi9-python-3.12/Dockerfile.cuda:152-159
Timestamp: 2025-08-27T14:49:24.112Z
Learning: jiridanek requested GitHub issue creation for CUDA version alignment in pytorch+llmcompressor runtime during PR #2145 review. Issue #2148 was created addressing the mismatch between Dockerfile CUDA 12.6 and pylock.toml cu124 PyTorch wheels. The issue includes comprehensive problem description covering affected files (runtimes/pytorch+llmcompressor/ubi9-python-3.12/Dockerfile.cuda and pylock.toml), detailed solution with PyTorch index URL update from cu124 to cu126, lock regeneration steps using uv, clear acceptance criteria for wheel alignment verification, and proper context linking to PR #2145 review comment, assigned to jiridanek.
Applied to files:
rstudio/c9s-python-3.11/Dockerfile.cuda
📚 Learning: 2025-08-20T12:18:19.213Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2000
File: runtimes/pytorch/ubi9-python-3.12/requirements.txt:804-807
Timestamp: 2025-08-20T12:18:19.213Z
Learning: The runtimes/rocm-tensorflow/ubi9-python-3.12/requirements.txt file remained at jupyter-core==5.7.2 while other runtime images were updated to 5.8.1 during PR #2000 to address CVE-2025-30167. jiridanek requested a separate GitHub issue to track this remaining update as the reason for the file being stuck at the old version was unclear.
Applied to files:
rstudio/c9s-python-3.11/Dockerfile.cuda
📚 Learning: 2025-08-20T12:18:19.213Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2000
File: runtimes/pytorch/ubi9-python-3.12/requirements.txt:804-807
Timestamp: 2025-08-20T12:18:19.213Z
Learning: The runtimes/rocm-tensorflow/ubi9-python-3.12/requirements.txt file remained at jupyter-core==5.7.2 while other runtime images were updated to 5.8.1 during PR #2000 to address CVE-2025-30167. jiridanek requested a separate GitHub issue (#2055) to track this remaining update as the reason for the file being stuck at the old version was unclear.
Applied to files:
rstudio/c9s-python-3.11/Dockerfile.cuda
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (6)
- GitHub Check: build (cuda-rstudio-c9s-python-3.11, 3.11, linux/amd64, false) / build
- GitHub Check: build (rstudio-c9s-python-3.11, 3.11, linux/amd64, false) / build
- GitHub Check: build (rstudio-rhel9-python-3.11, 3.11, linux/amd64, true) / build
- GitHub Check: build (cuda-rstudio-rhel9-python-3.11, 3.11, linux/amd64, true) / build
- GitHub Check: Red Hat Konflux / odh-workbench-rstudio-minimal-cpu-py311-c9s-on-pull-request
- GitHub Check: Red Hat Konflux / odh-workbench-rstudio-minimal-cuda-py311-c9s-on-pull-request
🔇 Additional comments (3)
rstudio/rhel9-python-3.11/Dockerfile.cuda (1)
23-24
: Skip manual cache cleanup changes; defer to issue #2076
Cleanup patterns will be standardized repository-wide under issue #2076; leave this PR focused on skopeo removal.Likely an incorrect or invalid review comment.
scripts/dockerfile_fragments.py (2)
39-49
: Good guard: oc client excluded from RStudio paths.
110-112
: Helper looks correct and future-proof.
03c3fc7
to
b4151b1
Compare
b4151b1
to
b333006
Compare
@codeerabbitai full review |
@coderabbitai full teview |
, removing skopeo from RStudio images is an appropriate mitigation strategy. Technical Review1. Consistency Across RStudio Variants ✅The changes are consistently applied across all four RStudio Dockerfile variants:
Each removes both skopeo package installation and the OpenShift client (oc) installation block. 2. Proper Documentation ✅All removals include explanatory comments like 3. Script Logic Implementation ✅The
4. Functionality Impact Assessment ✅Based on the search results, neither skopeo nor the oc client appear to be actively used within RStudio-specific scripts or workflows, making their removal safe for RStudio functionality. 5. Scope Appropriateness ✅The change correctly targets only RStudio images while preserving skopeo and oc client installation in other notebook types (Jupyter, etc.) where they may still be needed. Recommendations
SummaryThis is a well-implemented security fix that appropriately addresses CVE-2025-4674 by removing the vulnerable skopeo package and the unneeded oc client from RStudio images. The implementation is consistent, well-documented, and maintains functionality for other notebook types. The changes align with security best practices of removing unnecessary attack surface. 🧠 Learnings used
✅ Actions performedFull review triggered. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
tests/containers/base_image_test.py (1)
95-99
: Guard the initialoc version
call for RStudio images
Wrap the unguarded invocation at lines 95–99 oftests/containers/base_image_test.py
in anif not utils.is_rstudio_image(image):
block, mirroring the other tests:- ecode, output = container.exec(["/bin/sh", "-c", "oc version"]) - logging.debug(output.decode()) - assert ecode == 0 + if not utils.is_rstudio_image(image): + ecode, output = container.exec(["/bin/sh", "-c", "oc version"]) + logging.debug(output.decode()) + assert ecode == 0
🧹 Nitpick comments (3)
rstudio/rhel9-python-3.11/Dockerfile.cuda (1)
173-174
: Typo in standard label key: use io.k8s., not io.k9s.Fixing keeps labels interoperable with tooling that keys on io.k8s.*.
- io.k9s.display-name="RStudio Server image with python 3.11 based on Red Hat Enterprise Linux 9" \ - io.k9s.description="RStudio Server image with python 3.11 based on Red Hat Enterprise Linux 9" \ + io.k8s.display-name="RStudio Server image with python 3.11 based on Red Hat Enterprise Linux 9" \ + io.k8s.description="RStudio Server image with python 3.11 based on Red Hat Enterprise Linux 9" \rstudio/rhel9-python-3.11/Dockerfile.cpu (1)
43-44
: Label key typo: io.k9s → io.k8sSame nit as CUDA variant; update for consistency with standard labels.
- io.k9s.display-name="RStudio Server image with python 3.11 based on Red Hat Enterprise Linux 9" \ - io.k9s.description="RStudio Server image with python 3.11 based on Red Hat Enterprise Linux 9" \ + io.k8s.display-name="RStudio Server image with python 3.11 based on Red Hat Enterprise Linux 9" \ + io.k8s.description="RStudio Server image with python 3.11 based on Red Hat Enterprise Linux 9" \scripts/dockerfile_fragments.py (1)
43-47
: Optional: prefer TARGETARCH mapping over uname -m in oc URLOrthogonal to this PR, but since you’re touching this area: prior issues flagged aarch64 vs arm64 mismatches. Using BuildKit’s TARGETARCH avoids host-leakage and arch mismaps.
Example (conceptual):
- RUN curl -L https://mirror.openshift.com/pub/openshift-v4/$(uname -m)/clients/ocp/stable/openshift-client-linux.tar.gz \ + ARG TARGETARCH + RUN case "$TARGETARCH" in amd64) ARCH=x86_64 ;; arm64) ARCH=arm64 ;; *) ARCH="$TARGETARCH" ;; esac; \ + curl -L "https://mirror.openshift.com/pub/openshift-v4/${ARCH}/clients/ocp/stable/openshift-client-linux.tar.gz" \ -o /tmp/openshift-client-linux.tar.gz && \ tar -xzvf /tmp/openshift-client-linux.tar.gz oc && \ rm -f /tmp/openshift-client-linux.tar.gzIf desired, I can open a follow-up issue and propagate this change across non-RStudio images.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
rstudio/c9s-python-3.11/Dockerfile.cpu
(1 hunks)rstudio/c9s-python-3.11/Dockerfile.cuda
(1 hunks)rstudio/rhel9-python-3.11/Dockerfile.cpu
(1 hunks)rstudio/rhel9-python-3.11/Dockerfile.cuda
(1 hunks)scripts/dockerfile_fragments.py
(2 hunks)tests/containers/base_image_test.py
(3 hunks)
🧰 Additional context used
🧠 Learnings (17)
📓 Common learnings
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: jupyter/pytorch/ubi9-python-3.12/Dockerfile.cuda:42-52
Timestamp: 2025-07-09T12:29:56.162Z
Learning: jiridanek requested GitHub issue creation for OpenShift client architecture mapping problem affecting 29 Dockerfiles during PR #1320 review. Issue was created with comprehensive analysis covering all affected files using $(uname -m) returning 'aarch64' but OpenShift mirror expecting 'arm64', systematic solution using BuildKit TARGETARCH mapping with proper amd64→x86_64 and arm64→arm64 conversion, detailed acceptance criteria, and implementation guidance, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2215
File: runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu:0-0
Timestamp: 2025-09-05T11:27:31.040Z
Learning: jiridanek requested GitHub issue creation for build toolchain optimization in datascience runtime during PR #2215 review. Issue #2308 was created addressing unnecessary build dependencies (gcc-toolset-13, cmake, ninja-build, rust, cargo) in final runtime image for ppc64le architecture, covering comprehensive problem analysis with specific line numbers, multiple solution options for builder-only toolchains, clear acceptance criteria for size reduction and security improvement, detailed implementation guidance for package segregation, and proper context linking to PR #2215 review comment, continuing the established pattern of systematic infrastructure improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1230
File: jupyter/minimal/ubi9-python-3.12/Dockerfile.cpu:21-24
Timestamp: 2025-07-01T06:48:13.154Z
Learning: jiridanek creates comprehensive follow-up issues from review comments that expand scope appropriately, include clear acceptance criteria, proper backlinks, and structured implementation guidance. Issue #1241 demonstrates this by turning a specific oc client checksum concern into a thorough security enhancement plan covering all downloaded binaries across the Python 3.12 implementation.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2367
File: .github/workflows/build-notebooks-pr-aipcc.yaml:68-79
Timestamp: 2025-09-09T18:48:54.058Z
Learning: jiridanek requested GitHub issue creation for pull_request_target workflow security hardening during PR #2367 review, specifically addressing the direct usage of github.event.pull_request.head.ref (untrusted branch names) in shell scripts within .github/workflows/build-notebooks-pr-aipcc.yaml. Issue was created with comprehensive security analysis covering low-medium risk assessment with existing permission check mitigation, detailed solution approach using environment variables and safe ref handling, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic security improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1909
File: runtimes/pytorch+llmcompressor/ubi9-python-3.11/Dockerfile.cuda:11-15
Timestamp: 2025-08-12T08:40:55.286Z
Learning: jiridanek requested GitHub issue creation for redundant CUDA upgrade optimization during PR #1909 review. Analysis revealed all 14 CUDA Dockerfiles contain redundant `yum upgrade -y` commands in cuda-base stages that execute after base stages already performed comprehensive `dnf upgrade` via pre-upgrade blocks, causing unnecessary CI latency and build inefficiency. Issue includes complete scope analysis with specific line numbers, investigation framework requiring NVIDIA upstream documentation review, multiple solution options, comprehensive acceptance criteria covering systematic testing and performance measurement, and proper context linking to PR #1909 review comment.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1230
File: jupyter/minimal/ubi9-python-3.12/Dockerfile.rocm:43-55
Timestamp: 2025-07-01T06:48:21.070Z
Learning: When security concerns are raised during PR reviews in opendatahub-io/notebooks, comprehensive follow-up issues are created (often by CodeRabbit) to track all related security enhancements with clear acceptance criteria and implementation guidance. This ensures security improvements are systematically addressed in dedicated efforts rather than blocking current deliverables.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-08-27T15:14:05.619Z
Learning: jiridanek requested GitHub issue creation for tensorflow-rocm dependency-metadata override reassessment during PR #2145 review, identifying that the current `requires-dist = []` approach may be dangerous and hard to maintain since environments already exclude Windows. Issue #2153 was created with comprehensive safety analysis covering metadata masking risks, maintenance concerns, investigation areas for necessity testing, multiple solution options from complete removal to targeted alternatives, and acceptance criteria for proper dependency management, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/pytorch/ubi9-python-3.12/Dockerfile.cuda:17-25
Timestamp: 2025-07-09T08:07:30.628Z
Learning: jiridanek requested GitHub issue creation for oc client installation permission problem in PyTorch CUDA runtime Dockerfile during PR #1333 review. Issue #1356 was created with comprehensive problem description covering USER 1001 permission conflicts with root-owned /opt/app-root/bin directory, detailed impact analysis of build failures and non-executable binaries, current problematic code snippet, complete solution with user switching approach, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/minimal/ubi9-python-3.12/requirements.txt:289-292
Timestamp: 2025-07-08T19:52:16.010Z
Learning: jiridanek requested GitHub issue creation for jupyter-core security upgrade to address CVE-2025-30167 during PR #1333 review. Issue #1351 was created with comprehensive security vulnerability description covering high-severity privilege escalation on Windows, affected files analysis, specific upgrade instructions from version 5.7.2 to 5.8.1+, detailed acceptance criteria for security verification and repository audit, phased implementation guidance, and proper context linking, continuing the established pattern of systematic security improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-11T11:16:05.131Z
Learning: jiridanek requested GitHub issue creation for RStudio py311 Tekton push pipelines during PR #1379 review. Issue #1384 was successfully created covering two RStudio variants (CPU and CUDA) found in manifests/base/params-latest.env, with comprehensive problem description, implementation requirements following the same pattern as other workbench pipelines, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2114
File: Makefile:22-24
Timestamp: 2025-08-27T07:37:13.713Z
Learning: In the opendatahub-io/notebooks repository, when transitioning from Python 3.11 to 3.12 as the default RELEASE_PYTHON_VERSION, RStudio images (both c9s and rhel9 variants) should retain Python 3.11 support, requiring the piplock-renewal.yaml workflow matrix to include both Python versions ["3.11", "3.12"].
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1760
File: jupyter/pytorch+llmcompressor/ubi9-python-3.11/Dockerfile.cuda:241-244
Timestamp: 2025-08-08T08:38:32.988Z
Learning: Policy: In opendatahub-io/notebooks, do not remove micropipenv from Python 3.11 images to avoid breaking existing users. Cleanups can deduplicate duplicate installs and remove unused uv, but micropipenv must remain present in 3.11 images.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#968
File: runtimes/rocm-tensorflow/ubi9-python-3.12/Dockerfile.rocm:17-18
Timestamp: 2025-08-06T15:33:47.175Z
Learning: During PR #968 review, CodeRabbit initially incorrectly identified 1 legitimate micropipenv usage in jupyter/tensorflow/ubi9-python-3.12/Dockerfile.cuda when analyzing Python 3.12 images for unused dependencies. Upon jiridanek's request for re-verification, comprehensive analysis revealed all 15 Python 3.12 Dockerfiles install micropipenv but none actually use it, making the cleanup scope 100% unnecessary installations with no exceptions to handle.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/Dockerfile.rocm:34-37
Timestamp: 2025-07-02T18:19:23.024Z
Learning: In the opendatahub-io/notebooks repository, issue #1241 "Security: Add checksum verification for downloaded binaries in Python 3.12 images" covers the security concern about verifying downloaded binaries including the oc client. Red Hat does not provide signed RPM packages for the OpenShift CLI (oc) in UBI9 official repositories, making manual binary download with checksum verification the recommended approach.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2185
File: jupyter/pytorch/ubi9-python-3.12/Dockerfile.cuda:109-117
Timestamp: 2025-08-29T08:48:55.985Z
Learning: jiridanek prefers to implement systematic cleanup improvements through dedicated GitHub issues (like #2076) rather than applying individual point fixes during PR reviews, maintaining consistency with their established pattern of comprehensive code quality improvements.
📚 Learning: 2025-08-12T08:40:55.286Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1909
File: runtimes/pytorch+llmcompressor/ubi9-python-3.11/Dockerfile.cuda:11-15
Timestamp: 2025-08-12T08:40:55.286Z
Learning: jiridanek requested GitHub issue creation for redundant CUDA upgrade optimization during PR #1909 review. Analysis revealed all 14 CUDA Dockerfiles contain redundant `yum upgrade -y` commands in cuda-base stages that execute after base stages already performed comprehensive `dnf upgrade` via pre-upgrade blocks, causing unnecessary CI latency and build inefficiency. Issue includes complete scope analysis with specific line numbers, investigation framework requiring NVIDIA upstream documentation review, multiple solution options, comprehensive acceptance criteria covering systematic testing and performance measurement, and proper context linking to PR #1909 review comment.
Applied to files:
rstudio/c9s-python-3.11/Dockerfile.cpu
rstudio/rhel9-python-3.11/Dockerfile.cuda
rstudio/c9s-python-3.11/Dockerfile.cuda
rstudio/rhel9-python-3.11/Dockerfile.cpu
📚 Learning: 2025-08-06T15:33:47.175Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#968
File: runtimes/rocm-tensorflow/ubi9-python-3.12/Dockerfile.rocm:17-18
Timestamp: 2025-08-06T15:33:47.175Z
Learning: During PR #968 review, CodeRabbit initially incorrectly identified 1 legitimate micropipenv usage in jupyter/tensorflow/ubi9-python-3.12/Dockerfile.cuda when analyzing Python 3.12 images for unused dependencies. Upon jiridanek's request for re-verification, comprehensive analysis revealed all 15 Python 3.12 Dockerfiles install micropipenv but none actually use it, making the cleanup scope 100% unnecessary installations with no exceptions to handle.
Applied to files:
rstudio/c9s-python-3.11/Dockerfile.cpu
rstudio/rhel9-python-3.11/Dockerfile.cuda
rstudio/c9s-python-3.11/Dockerfile.cuda
📚 Learning: 2025-07-04T10:41:13.061Z
Learnt from: grdryn
PR: opendatahub-io/notebooks#1320
File: rstudio/rhel9-python-3.11/Dockerfile.cuda:34-35
Timestamp: 2025-07-04T10:41:13.061Z
Learning: In the opendatahub-io/notebooks repository, when adapting NVIDIA CUDA Dockerfiles, the project intentionally maintains consistency with upstream NVIDIA patterns even when it might involve potential risks like empty variable expansions in package installation commands. This is considered acceptable because the containers only run on RHEL 9 with known yum/dnf behavior, and upstream consistency is prioritized over defensive coding practices.
Applied to files:
rstudio/c9s-python-3.11/Dockerfile.cpu
rstudio/rhel9-python-3.11/Dockerfile.cuda
rstudio/c9s-python-3.11/Dockerfile.cuda
rstudio/rhel9-python-3.11/Dockerfile.cpu
📚 Learning: 2025-09-05T12:10:50.856Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2215
File: runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu:0-0
Timestamp: 2025-09-05T12:10:50.856Z
Learning: jiridanek requested GitHub issue creation for Dockerfile environment variable refactoring during PR #2215 review. Issue #2311 was created addressing build-only variables (OPENBLAS_VERSION, ONNX_VERSION, GRPC_PYTHON_BUILD_SYSTEM_OPENSSL) being unnecessarily written to /etc/profile.d/ppc64le.sh in runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu, causing variable duplication across stages, unreliable sourcing in non-login build contexts, and violation of DRY principles. The issue includes comprehensive problem description covering affected lines 30-37, detailed impact analysis of build reliability and maintenance overhead, three solution options with centralized ARG/ENV approach as recommended, clear acceptance criteria for version centralization and build-only variable cleanup, and specific implementation guidance with code examples, assigned to jiridanek, continuing the established pattern of systematic infrastructure improvements through detailed issue tracking.
Applied to files:
rstudio/c9s-python-3.11/Dockerfile.cpu
rstudio/rhel9-python-3.11/Dockerfile.cuda
rstudio/c9s-python-3.11/Dockerfile.cuda
rstudio/rhel9-python-3.11/Dockerfile.cpu
📚 Learning: 2025-09-05T12:25:09.719Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2227
File: codeserver/ubi9-python-3.12/Dockerfile.cpu:122-123
Timestamp: 2025-09-05T12:25:09.719Z
Learning: jiridanek requested GitHub issue creation for Docker multi-stage synchronization improvement in codeserver/ubi9-python-3.12/Dockerfile.cpu during PR #2227 review. The issue addresses sentinel file pattern using /tmp/control copied to /dev/null for stage coordination between rpm-base, whl-cache, and codeserver stages, proposing semantic improvements with descriptive file names, inline documentation, and elimination of /dev/null hack while maintaining multi-architecture build functionality for ppc64le support.
Applied to files:
rstudio/c9s-python-3.11/Dockerfile.cpu
rstudio/rhel9-python-3.11/Dockerfile.cpu
📚 Learning: 2025-09-05T12:10:50.856Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2215
File: runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu:0-0
Timestamp: 2025-09-05T12:10:50.856Z
Learning: jiridanek requested GitHub issue creation for Dockerfile environment variable refactoring during PR #2215 review. Issue addresses build-only variables (OPENBLAS_VERSION, ONNX_VERSION, GRPC_PYTHON_BUILD_SYSTEM_OPENSSL) being unnecessarily written to /etc/profile.d/ppc64le.sh in runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu, causing variable duplication across stages, unreliable sourcing in non-login build contexts, and violation of DRY principles. The issue includes comprehensive problem description covering affected lines 30-37, detailed impact analysis of build reliability and maintenance overhead, three solution options with centralized ARG/ENV approach as recommended, clear acceptance criteria for version centralization and build-only variable cleanup, and specific implementation guidance with code examples, continuing the established pattern of systematic infrastructure improvements through detailed issue tracking.
Applied to files:
rstudio/c9s-python-3.11/Dockerfile.cpu
rstudio/rhel9-python-3.11/Dockerfile.cuda
rstudio/rhel9-python-3.11/Dockerfile.cpu
📚 Learning: 2025-08-06T15:22:17.997Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#968
File: runtimes/rocm-tensorflow/ubi9-python-3.12/Dockerfile.rocm:17-18
Timestamp: 2025-08-06T15:22:17.997Z
Learning: jiridanek requested GitHub issue creation for micropipenv removal from Python 3.12 images during PR #968 review. Analysis revealed 15 affected Dockerfiles with only 1 legitimate usage (jupyter/tensorflow/ubi9-python-3.12/Dockerfile.cuda using micropipenv install --dev) while 14 images install micropipenv unnecessarily. Issue #1685 was created with comprehensive problem description covering ~238MB total waste across unused installations, detailed scope analysis, multiple solution options, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Applied to files:
rstudio/c9s-python-3.11/Dockerfile.cpu
rstudio/rhel9-python-3.11/Dockerfile.cuda
rstudio/c9s-python-3.11/Dockerfile.cuda
📚 Learning: 2025-08-27T18:54:33.532Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-08-27T18:54:33.532Z
Learning: jiridanek requested GitHub issue creation for comment typo fix during PR #2145 review, specifically fixing "hhttps" to "https" in rstudio/rhel9-python-3.11/Dockerfile.cuda line 139 NVIDIA CUDA Dockerfile reference. Issue #2164 was created with comprehensive problem description, clear before/after solution, and acceptance criteria, continuing the established pattern of systematic code quality improvements through detailed issue tracking for even minor documentation fixes.
Applied to files:
rstudio/c9s-python-3.11/Dockerfile.cpu
rstudio/rhel9-python-3.11/Dockerfile.cuda
rstudio/c9s-python-3.11/Dockerfile.cuda
rstudio/rhel9-python-3.11/Dockerfile.cpu
📚 Learning: 2025-09-05T12:25:58.344Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2227
File: codeserver/ubi9-python-3.12/Dockerfile.cpu:126-128
Timestamp: 2025-09-05T12:25:58.344Z
Learning: jiridanek expressed concern about code-server installation complexity in codeserver/ubi9-python-3.12/Dockerfile.cpu during PR #2227 review, describing the multi-stage cache mount approach as a "hack" that worries them. GitHub issue #2315 was created addressing the architectural complexity with comprehensive problem description, four solution options, clear acceptance criteria, and implementation considerations, assigned to jiridanek, continuing the established pattern of systematic technical improvement tracking.
Applied to files:
rstudio/c9s-python-3.11/Dockerfile.cpu
rstudio/rhel9-python-3.11/Dockerfile.cpu
📚 Learning: 2025-09-05T12:25:58.344Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2227
File: codeserver/ubi9-python-3.12/Dockerfile.cpu:126-128
Timestamp: 2025-09-05T12:25:58.344Z
Learning: jiridanek expressed concern about code-server installation complexity in codeserver/ubi9-python-3.12/Dockerfile.cpu during PR #2227 review, describing the multi-stage cache mount approach as a "hack" that worries them, leading to GitHub issue creation for systematic architectural improvement addressing maintainability concerns.
Applied to files:
rstudio/c9s-python-3.11/Dockerfile.cpu
rstudio/rhel9-python-3.11/Dockerfile.cpu
📚 Learning: 2025-07-02T18:19:23.024Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/Dockerfile.rocm:34-37
Timestamp: 2025-07-02T18:19:23.024Z
Learning: In the opendatahub-io/notebooks repository, issue #1241 "Security: Add checksum verification for downloaded binaries in Python 3.12 images" covers the security concern about verifying downloaded binaries including the oc client. Red Hat does not provide signed RPM packages for the OpenShift CLI (oc) in UBI9 official repositories, making manual binary download with checksum verification the recommended approach.
Applied to files:
rstudio/c9s-python-3.11/Dockerfile.cpu
rstudio/rhel9-python-3.11/Dockerfile.cuda
rstudio/c9s-python-3.11/Dockerfile.cuda
rstudio/rhel9-python-3.11/Dockerfile.cpu
📚 Learning: 2025-08-12T08:40:55.286Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1909
File: runtimes/pytorch+llmcompressor/ubi9-python-3.11/Dockerfile.cuda:11-15
Timestamp: 2025-08-12T08:40:55.286Z
Learning: jiridanek requested GitHub issue creation for redundant CUDA upgrade optimization during PR #1909 review. Issue covers duplicate yum/dnf upgrade commands in cuda-base stages that execute after base stages already performed comprehensive upgrades, causing unnecessary CI latency and build inefficiency across multiple CUDA Dockerfiles. The solution requires investigating NVIDIA upstream documentation requirements before removing redundant upgrades, with systematic testing of all CUDA variants and performance measurement. Issue follows established pattern of comprehensive problem analysis, multiple solution options, detailed acceptance criteria, and proper context linking.
Applied to files:
rstudio/rhel9-python-3.11/Dockerfile.cuda
rstudio/c9s-python-3.11/Dockerfile.cuda
📚 Learning: 2025-08-27T18:58:27.554Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-08-27T18:58:27.554Z
Learning: jiridanek requested GitHub issue creation for URL typo fix during PR #2145 review, identifying "hhttps" instead of "https" in rstudio/rhel9-python-3.11/Dockerfile.cuda line 139. Issue #2166 was created with specific line reference, before/after diff, and acceptance criteria for this minor but important documentation accuracy fix, demonstrating attention to detail in code review process.
Applied to files:
rstudio/rhel9-python-3.11/Dockerfile.cuda
rstudio/c9s-python-3.11/Dockerfile.cuda
rstudio/rhel9-python-3.11/Dockerfile.cpu
📚 Learning: 2025-08-27T15:05:31.656Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#2145
File: jupyter/trustyai/ubi9-python-3.12/Dockerfile.cpu:134-140
Timestamp: 2025-08-27T15:05:31.656Z
Learning: jiridanek requested GitHub issue creation for CUDA wheel optimization in TrustyAI CPU image during PR #2145 review. The CPU Dockerfile currently uses pylock.toml with CUDA-enabled PyTorch wheels (torch==2.6.0+cu126) which was previously discussed with harshad16 and grdryn but deferred. Issue created with comprehensive problem analysis covering unnecessary CUDA wheels in CPU-only image, multiple solution options including lock regeneration and separate CPU/CUDA files, clear acceptance criteria for wheel optimization verification, and proper context linking to PR #2145 review comment.
Applied to files:
rstudio/rhel9-python-3.11/Dockerfile.cuda
rstudio/c9s-python-3.11/Dockerfile.cuda
📚 Learning: 2025-08-27T19:00:57.755Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-08-27T19:00:57.755Z
Learning: jiridanek requested GitHub issue creation for tensorflow[and-cuda] extra removal investigation during PR #2145 review, addressing the concern that this extra forces CUDA-specific wheels causing cross-platform conflicts while Docker images already supply CUDA via base layer. Issue #2168 was created with comprehensive investigation framework covering dependency differences, runtime verification, performance testing, cross-platform compatibility, and clear acceptance criteria for deciding whether to remove the extra in favor of base tensorflow package.
Applied to files:
rstudio/c9s-python-3.11/Dockerfile.cuda
📚 Learning: 2025-07-09T12:29:56.162Z
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1320
File: jupyter/pytorch/ubi9-python-3.12/Dockerfile.cuda:42-52
Timestamp: 2025-07-09T12:29:56.162Z
Learning: jiridanek requested GitHub issue creation for OpenShift client architecture mapping problem affecting 29 Dockerfiles during PR #1320 review. Issue was created with comprehensive analysis covering all affected files using $(uname -m) returning 'aarch64' but OpenShift mirror expecting 'arm64', systematic solution using BuildKit TARGETARCH mapping with proper amd64→x86_64 and arm64→arm64 conversion, detailed acceptance criteria, and implementation guidance, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Applied to files:
rstudio/rhel9-python-3.11/Dockerfile.cpu
🔇 Additional comments (9)
rstudio/c9s-python-3.11/Dockerfile.cpu (1)
26-27
: Remove skopeo: security mitigation looks goodChange is minimal and consistent with the stated CVE mitigation. Cache cleanup remains intact.
rstudio/rhel9-python-3.11/Dockerfile.cuda (1)
23-24
: Remove skopeo from base: OKMatches the PR goal; no other regressions evident in this stage.
rstudio/c9s-python-3.11/Dockerfile.cuda (1)
28-29
: Skopeo removal in CUDA variant: OKAligned with CPU variant; comment provides traceability to CVE.
tests/containers/base_image_test.py (3)
131-133
: Skip oc check for RStudio images: OKGuard aligns tests with image contents.
142-144
: Skip skopeo check for RStudio images: OKConsistent with skopeo removal.
171-173
: Skip oc/FIPS check for RStudio images: OKPrevents false negatives after oc removal.
rstudio/rhel9-python-3.11/Dockerfile.cpu (1)
21-22
: Remove skopeo: OKMatches CVE intent; rest of Dockerfile unchanged.
scripts/dockerfile_fragments.py (2)
39-49
: Good guard: oc block excluded for RStudio DockerfilesThe is_rstudio() gate cleanly limits oc injection to non-RStudio images.
110-112
: Helper looks correctis_relative_to(ROOT_DIR / "rstudio") is clear and efficient.
|
||
# Other apps and tools installed as default user | ||
USER 1001 | ||
|
||
# Install the oc client begin |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the oc bring also cves?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, so does skopeo. Issues already filed in both of those projects. Happy to provide links if needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we agreed for oc removal then i am not against
/lgtm
…Studio Dockerfiles to address CVE-2025-4674
originally introduced in * opendatahub-io#940
b333006
to
8b7d74a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: daniellutz The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@jiridanek: The following tests failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
Build failure in RHEL9 based cuda image is expected
File's been missing from earlier this week, it's not something I caused right now. |
https://issues.redhat.com/browse/RHAIENG-987
Description
Gone, babe, she's gone
How Has This Been Tested?
Merge criteria:
Summary by CodeRabbit
Security
Chores
Refactor
Tests