Repository navigation
Conversation
…ident Raise packages below the fixed versions from the Python security advisory (https://discuss.python.org/t/109576): - ci/pixi-version.env: pixi v0.73.0 -> v0.82.1 - pypa/cibuildwheel v4.3.1 -> v4.3.4 - pypa/gh-action-pypi-publish v1.14.2 -> v1.14.3 - pixi lockfiles: certifi 2026.10.19, pip 26.2.2, uv 0.13.5 and ca-certificates 2026.10.19, updated per package with pixi 0.82.1 (no general refresh, per the lockfile maintenance pause) Known gaps: the source-package host environments in the two benchmarks workspaces still lock uv 0.12.23; they cannot currently be re-solved. Refs NVIDIA#3195 Signed-off-by: Ralf Juengling <rjuengling@nvidia.com>
Follow-up to the eMudhra/emSign CA remediation: lock uv 0.13.5 (and ca-certificates 2026.10.19) in the host environments of the source packages in benchmarks/cuda_bindings and benchmarks/cuda_core. These could not be re-solved with the committed manifests because the benchmark workspaces pin python = "3.14.*" but define no build-variants, so the re-evaluated source packages required python_abi 3.15. The lockfiles were updated with a temporary [workspace.build-variants] python = ["3.14.*"] entry (plus a temporary uv dependency) in each pixi.toml, both reverted afterwards. The manifests are unchanged. Re-solving also moved a few unrelated packages (cuda-pathfinder 1.8.4, CUDA 13.4.92 build 1, python 3.14.9, setuptools, binutils builds). benchmarks/cuda_core/pixi.lock still fails `pixi lock --check`, as it did before this change. Refs NVIDIA#3195 Signed-off-by: Ralf Juengling <rjuengling@nvidia.com>
|
Ralf, #3197 looks good to me. All seven pin SHAs match the v4.3.4 and v1.14.3 tags. Every One gap: CI still runs pip older than 26.2.2. The
The pathfinder python -m pip install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70" |
|
/ok to test a417bd8 |
📝 Summary
Priority: ➖ Normal Change: Other Merge Risk: 🔵 Low · up to
|
There was a problem hiding this comment.
Actionable comments posted: 1
ℹ️ Review info
⚙️ Run configuration
- Source mode: Auto
- Repository: NVIDIA/cuda-python
- Branch: main
- File: .coderabbit.yaml
- Commit: afa6249
- Layers: Repository YAML
- Review profile: CHILL
- Plan: Enterprise
- Run ID:
befe61a4-aaa8-4b68-b31a-7e18bcc4719a
⛔ Files ignored due to path filters: 6
benchmarks/cuda_bindings/pixi.lockis excluded by!**/*.lockbenchmarks/cuda_core/pixi.lockis excluded by!**/*.lockcuda_bindings_13/pixi.lockis excluded by!**/*.lockcuda_core/pixi.lockis excluded by!**/*.lockcuda_pathfinder/pixi.lockis excluded by!**/*.lockpixi.lockis excluded by!**/*.lock
📒 Files selected for processing: 5
.github/workflows/build-wheel.yml.github/workflows/release-cuda-pathfinder.yml.github/workflows/release.ymlci/README.mdci/pixi-version.env
Included review availability: This review used your included allowance. Your plan provides up to 12 included reviews per hour; 11 remain after this review.
Andy-Jost noted on NVIDIA#3197 that setup-python ships the old ensurepip pip, and our `pip>=25.1`/`pip>=25.3` floors neither force 26.2.2 nor protect the upgrade download itself. Any pip before 26.2.2 loads its vendored certifi, which trusts the compromised eMudhra/emSign intermediate CAs. Add a reusable `.github/actions/harden-pip` composite action that installs pip 26.2.2 from a sha256-pinned wheel (integrity is guaranteed by the hash even when the bootstrapping pip's trust store is compromised), and invoke it right after each setup-python / `python -m venv` and before the first pip network call in the affected workflows: - build-wheel.yml (both setup-python steps; covers twine and the shipped pathfinder/cuda-python `pip wheel` builds) - test-wheel-linux.yml, test-wheel-windows.yml - test-sdist-linux.yml, test-sdist-windows.yml (drop the now-redundant "pip>=25.3" token) - coverage.yml (all four venv/setup-python jobs; replaces the "pip>=25.3" upgrades) - pre-commit.yml (drops the unprotected `--upgrade pip`) - ci-nightly.yml (CI-tools job on the runner's system python) - lychee-links composite action (covers lychee.yml and build-docs.yml link checks) Refs NVIDIA#3195, NVIDIA#3197 Signed-off-by: Ralf Juengling <rjuengling@nvidia.com>
|
/ok to test 72dff4d |
There was a problem hiding this comment.
Actionable comments posted: 1
ℹ️ Review info
⚙️ Run configuration
- Source mode: Auto
- Repository: NVIDIA/cuda-python
- Branch: main
- File: .coderabbit.yaml
- Commit: afa6249
- Layers: Repository YAML
- Review profile: CHILL
- Plan: Enterprise
- Run ID:
d08cfa2f-cea1-45c7-b687-1da2a1e36f79
📒 Files selected for processing: 10
.github/actions/harden-pip/action.yml.github/actions/lychee-links/action.yml.github/workflows/build-wheel.yml.github/workflows/ci-nightly.yml.github/workflows/coverage.yml.github/workflows/pre-commit.yml.github/workflows/test-sdist-linux.yml.github/workflows/test-sdist-windows.yml.github/workflows/test-wheel-linux.yml.github/workflows/test-wheel-windows.yml
Included review availability: This review used your included allowance. Your plan provides up to 12 included reviews per hour; 10 remain after this review.
|
CodeRabbit noted on NVIDIA#3197 that the wheel test jobs check out inputs.sha, which in nightly runs is the head of the last successful main CI run and can predate the harden-pip action. A ./.github/actions reference resolves against that checkout, so every nightly wheel-test job would fail at "Harden pip" until a main CI run that includes the action succeeds (the same pitfall NVIDIA#3052 worked around for download-artifact-retry). Reference the action with GitHub's self-repository syntax instead, which resolves at the running workflow's commit regardless of the checkout. It requires runner 2.336.0 or newer; the GPU runners report 2.337.0. actionlint v1.7.12, the latest release, does not yet recognize $/ (rhysd/actionlint#711), so add narrow per-file ignores for it. Refs NVIDIA#3195, NVIDIA#3197 Signed-off-by: Ralf Juengling <rjuengling@nvidia.com>
|
/ok to test 7d93e3b |
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to GitHub limitations.
🟡 Minor · important: Harden the Pathfinder verification environments… · release-cuda-pathfinder.yml:252-260
.github/workflows/release-cuda-pathfinder.yml:252-260
🔒 Security & Privacy | 🟡 Minor | ⚡ Quick winimportant: Harden the Pathfinder verification environments before installing packages.
Both verification jobs create a virtual environment and immediately run
pip install. Neither job invokesharden-pip, so the release checks use the venv-bootstrap pip instead of pinned pip 26.2.2. The checks can therefore pass with the outdated pip that this change is intended to replace.Suggested fix
- - name: Install from TestPyPI and verify + - name: Create verification environment run: | python3 -m venv /tmp/verify + - name: Harden pip + uses: $/.github/actions/harden-pip + with: + python: /tmp/verify/bin/python + - name: Install from TestPyPI and verify + run: | source /tmp/verify/bin/activate max_attempts=6 retry_seconds=30Apply the same change to
verify-pypi, using/tmp/verify/bin/pythonbefore its firstpip install.
🟡 Minor · 🎯 Functional Correctness · release.yml:330-333
.github/workflows/release.yml:330-333
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winimportant: Harden the verification environments before installing from TestPyPI or PyPI.
The release verification jobs create a virtual environment and run
pip installwithout invokingharden-pip. Those installs therefore use the version bootstrapped byvenv, not the hash-pinned pip 26.2.2 used by the other updated workflows. Pass each verification environment's Python executable toharden-pipbefore the first install. Otherwise, release verification does not use the pinned pip version for its package downloads.
ℹ️ Review info
⚙️ Run configuration
- Source mode: Auto
- Repository: NVIDIA/cuda-python
- Branch: main
- File: .coderabbit.yaml
- Commit: afa6249
- Layers: Repository YAML
- Review profile: CHILL
- Plan: Enterprise
- Run ID:
ec408da4-3dc9-467f-b970-aeaa4b22dfac
📒 Files selected for processing: 3
.github/actionlint.yaml.github/workflows/test-wheel-linux.yml.github/workflows/test-wheel-windows.yml
Included review availability: This review used your included allowance. Your plan provides up to 12 included reviews per hour; 10 remain after this review.
Raise packages below the fixed versions from the Python security advisory (https://discuss.python.org/t/109576):
ci/pixi-version.env: pixi v0.73.0 -> v0.82.1pypa/cibuildwheelv4.3.1 -> v4.3.4pypa/gh-action-pypi-publishv1.14.2 -> v1.14.3ci/README.md: the pause section no longer claims the pixi pin and lockfiles are unchangedRefs #3195
Commits
ci/README.md, and the root,cuda_pathfinder,cuda_bindings_13andcuda_corelockfiles, plusca-certificatesin the benchmark lockfiles.benchmarks/cuda_bindingsandbenchmarks/cuda_core.Notes for reviewers
uvis not a dependency of any environment; it appears only in thehost_packagesof the pixi-build source packages, sopixi update uvcannot target it. In each workspace I temporarily addeduv = "*"topixi.toml, updated the source packages, and reverted the manifest. Nopixi.tomlis changed by this PR.python = "3.14.*"but define no[workspace.build-variants], so re-solving their source packages failed (the re-evaluated packages requiredpython_abi 3.15). The second commit used a temporarypython = ["3.14.*"]build variant to get past this, also reverted afterwards.cuda-pathfinder1.8.4, CUDA 13.4.92 build_1(includingcuda-bindings13.4.4 incuda_core),binutilsbuilds, Python 3.14.9 / 3.15.1 andsetuptoolsin nested host environments.backports.strenumwas dropped from thecuda_corelockfiles; the committed locks were already stale after the Python 3.10 drop.pixi lock --checkpasses forcuda_pathfinder,cuda_bindings_13andbenchmarks/cuda_bindings.cuda_coreandbenchmarks/cuda_corestill fail it as before this change (consistent with pixi#7215, still open); the root lockfile was not checked.12.9.xbackport branch has not been checked for the same pins.Signed-off-by: Ralf Juengling rjuengling@nvidia.com