fix(release): unblock x86_64 minos verify + CI pip-audit gate - #155
Merged
Conversation
NumPy 2.x dropped older macOS wheel targets — its only cp312 x86_64 wheels are tagged macosx_14_0, which trip the minos<=11.0 verify gate that protects Big Sur (11.x) installs. Cap the constraint to <2.0 so pip lands on 1.26.4, which still ships macosx_10_9_x86_64 cp312 wheels. Also wire MACOSX_DEPLOYMENT_TARGET=11.0 into the /local-release skill's x86_64 install step, mirroring .github/workflows/release.yml. The env var alone doesn't fix the wheel resolution (no macosx_11_0 wheel exists for numpy 2.0.x), but it keeps pip's tag preference consistent with CI on Tahoe (macOS 26.x) hosts. Surfaced during the v0.19.0 local release; documented in docs/tickets/high-2026-04-28-fix-x86_64-numpy-minos-constraint.md.
The runner-shipped pip 26.0.1 is flagged by `pip-audit` for CVE-2026-3219 (tar/ZIP polyglot confusion), failing the Audit dependencies step and cancelling the rest of the matrix via fail-fast. v0.17.1 / v0.18.0 / v0.19.0 release.yml runs all died here; tarballs have been coming from the local-release flow rather than CI. The CVE has minimal realistic surface in this build (closed PyPI install, no user-supplied package names, pip is not bundled in the released binary) but pip-audit is correct to flag it. pip 26.1 ships the fix. Documented in docs/tickets/urgent-2026-04-28-fix-ci-pip-audit-cve-block.md.
rutefig
changed the title
Two review findings on PR #155: 1. constraints-x86_64.txt previously claimed numpy 2.0+ ships only macosx_14_0_x86_64 cp312 wheels. Verified via `pip download --platform macosx_11_0_x86_64 'numpy>=2.0,<2.1'` that 2.0.2 also ships a macosx_10_9_x86_64 wheel. The cap is still correct because pip on macOS 14+ runners prefers the higher-targeted (macosx_14_0) wheel; rewording to reflect that. 2. SKILL.md previously claimed MACOSX_DEPLOYMENT_TARGET=11.0 makes pip's wheel-tag preference match CI. Verified via packaging.tags that sys_tags() emits identical macosx_26_0 tags with and without the env var on a Tahoe host. The env still mirrors CI for any build-time tooling that reads it (PyInstaller bootloader, source builds), but wheel selection follows host macOS tags. Rewording to match. No code change — comment accuracy only.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two release-pipeline fixes that together unblock end-to-end CI release:
1. x86_64 numpy minos regression —
pin numpy<2.0Local-release flow: NumPy 2.x dropped older macOS wheel targets — its only cp312 x86_64 wheels are tagged
macosx_14_0. The existing constraintnumpy<2.1allowed pip to pullnumpy 2.0.2, whose_multiarray_umath.sohasLC_BUILD_VERSION minos=14.0— failing theminos<=11.0Big Sur gate. Capping to<2.0lands pip on1.26.4, which shipsmacosx_10_9_x86_64cp312 wheels (minos 10.9, passes).Skill change adds
MACOSX_DEPLOYMENT_TARGET=11.0to the local x86_64 install step, mirroring the workflow-level env var in.github/workflows/release.yml:14. The env var alone wouldn't have fixed the wheel resolution (nomacosx_11_0cp312 wheel exists for numpy 2.0.x), but it keeps pip's tag preference consistent with CI on Tahoe (macOS 26.x) hosts.Gitignore catches arch-suffixed venvs (
.venv-x86_64/) the skill creates during--arch x86_64and--arch bothbuilds.2. CI pip-audit gate blocked by CVE-2026-3219 — upgrade pip to >=26.1
release.ymlhas been failing at the Audit dependencies step on every recent tag push (v0.17.1, v0.18.0, v0.19.0 confirmed). Runner-shipped pip 26.0.1 is flagged bypip-auditfor CVE-2026-3219 (tar/ZIP polyglot confusion in archive-format detection). pip 26.1 ships the fix. The arm64 job exits non-zero, matrixfail-fastcancels x86_64, andrelease/promote-latest/verify-installall skip. Released artifacts have been coming from/local-releaseinstead of CI for the last three tags.The CVE is real (CVSS 4.6 MEDIUM, integrity-only, requires user interaction) but realistically low risk against this build — closed PyPI install, fixed package list, pip is not bundled in the released binary. Worth patching anyway since the fix is one line.
Verified
pip install --dry-runwith the new constraint resolves tonumpy-1.26.4-cp312-cp312-macosx_10_9_x86_64.whl✅_multiarray_umath.cpython-312-darwin.soLC_VERSION_MIN_MACOSX is 10.9 ✅screencap-0.19.0-x86_64.tar.gz(with the manual numpy override) passed minos verify and the 9-check_smoke-testTest plan
References