Summary

The dependency-audit CI job in .github/workflows/ci.yml runs pip install --upgrade pip before installing the project and pip-audit. This is a workaround for a runner-image lag, not a permanent step. Filing this issue so the workaround doesn't quietly outlive its reason.

Context

CVE-2026-3219 (pip 26.0.1 archive-handling, GHSA-58qw-9mgm-455v) was fixed in pip 26.1, released 2026-04-26. Vera's #527 removed the --ignore-vuln CVE-2026-3219 flag in v0.0.121 because the upstream fix had landed.

The dependency-audit CI job then started failing on PR #536 with:

Found 1 known vulnerability in 1 package
Name Version ID            Fix Versions
pip  26.0.1  CVE-2026-3219

Root cause: actions/setup-python@v6 bakes a specific pip version into each Python toolchain release (currently pip 26.0.1 for Python 3.12). The runner image doesn't track PyPI live — it updates when GitHub refreshes the toolchain. So pip-audit running inside the runner scans the runner's own pip and finds it vulnerable, regardless of what's available on PyPI.

Fix in PR #536 (commit 05ede31):

-        run: pip install -e . && pip install pip-audit
+        run: pip install --upgrade pip && pip install -e . && pip install pip-audit

The --upgrade pip pulls pip 26.1 from PyPI, replacing the bundled 26.0.1, before pip-audit scans the environment.

Removal trigger

When actions/setup-python@v6 ships a runner image with pip ≥ 26.1 natively, drop the pip install --upgrade pip from the Install dependencies and pip-audit step. The audit will then return clean against the runner's bundled pip without the upgrade.

To verify: the next time someone touches .github/workflows/ci.yml, they can check the GitHub-hosted runner release notes for actions/runner-images — search for pip in the recent monthly release notes. Once the version is ≥ 26.1, this issue's fix can be reverted.

Alternatively: GitHub Actions sometimes silently updates pip in setup-python@v6 in patch releases. A quick way to test: temporarily remove the --upgrade pip and watch dependency-audit — if it passes, the runner has caught up and this issue can be closed.

Why a permanent --upgrade pip would be wrong

Leaving --upgrade pip in indefinitely is harmless functionally but:

1. Adds 5–10s to every CI run (pip downloads + reinstalls itself)
2. Introduces a non-deterministic dependency on whatever pip is currently latest on PyPI — a future pip release with a regression we don't want would be silently picked up
3. Hides what the CI is actually testing (the runner's bundled toolchain)

Better to drop it as soon as the runner's bundled pip is the patched version.

Action items

• Periodically check actions/runner-images release notes for the bundled pip version
• When bundled pip ≥ 26.1: remove pip install --upgrade pip && from .github/workflows/ci.yml dependency-audit step
• Remove the corresponding row from KNOWN_ISSUES.md "CI workarounds" section
• Close this issue