Constrain cryptography below 49 on Intel Macs by Paul-Antoine-Bonin · Pull Request #56 · facebookresearch/autoform-bot

Paul-Antoine-Bonin · 2026-10-02T16:25:59Z

cryptography stopped publishing x86_64 macOS wheels at 49.0.0. Without a wheel, uv builds it from source, which needs Rust and OpenSSL headers, so both MCP servers (autoform-lsp, autoform-repl) fail to start on Intel Macs.

This adds a [tool.uv] constraint cryptography<49 scoped to sys_platform == 'darwin' and platform_machine == 'x86_64' and relocks. Other platforms keep 50.0.0.

Reproduction, resolving the locked requirements with prebuilt wheels only:

Target	`main`	this branch
x86_64-apple-darwin	no solution (`cryptography==50.0.0` has no usable wheels)	`cryptography==48.0.1`
aarch64-apple-darwin	`cryptography==50.0.0`	`cryptography==50.0.0`
x86_64-manylinux_2_28	`cryptography==50.0.0`	`cryptography==50.0.0`

uv run pytest -q: 762 passed; the one failure (test_the_generated_script_is_valid_javascript) also fails on main on my machine and comes from a local node binary. ruff check passes.

@Deicyde, Vivien suggested I send this your way.

cryptography stopped publishing x86_64 macOS wheels at 49.0.0. Without a wheel, uv builds it from source, which needs Rust and OpenSSL headers, so both MCP servers fail to start on Intel Macs. The constraint only applies to that platform; other platforms keep 50.0.0.

Deicyde

The constraint and lock are correct. I reproduced the failure on current main with:\n\n\n\nMain exits 2 because cryptography 50 has no usable wheel; this head exits 0 with 48.0.1, while arm64 macOS and x86_64 Linux retain 50.0.0.\n\nPlease add a focused regression for that platform resolution, since the normal Linux matrix cannot catch the original bug. A small test can combine the wheel-only dry run above with assertions for 48.0.1 on Intel macOS and 50.0.0 on arm64 macOS/Linux.

Deicyde · 2026-10-02T16:42:05Z

Correction: the exact regression commands omitted from my review are:

uv sync --locked --dry-run --no-build --no-cache --offline \
  --no-install-project --python-platform x86_64-apple-darwin
uv tree --locked --python-platform x86_64-apple-darwin
uv tree --locked --python-platform aarch64-apple-darwin
uv tree --locked --python-platform x86_64-manylinux_2_28

The first command fails on current main and succeeds on this head.

The Linux CI matrix cannot observe the missing x86_64 macOS wheels, so the test resolves the committed lock per platform: a wheel-only dry run for x86_64 macOS, cryptography below 49 there, and 49 or above on arm64 macOS and Linux.

Paul-Antoine-Bonin · 2026-10-02T17:03:26Z

Thanks for reproducing it! I added tests/test_lock_platforms.py. It only reads uv.lock (no network) and checks that:

Intel macOS installs with prebuilt wheels only (your dry run)
Intel macOS stays on cryptography < 49, since 49.0.0 is the first release without x86_64 macOS wheels (today that's 48.0.1)
arm64 macOS and Linux are not affected and keep cryptography >= 49 (today 50.0.0)

I compare against 49 rather than the exact versions, so the test keeps passing when the lock picks up a new patch release. Happy to pin 48.0.1 / 50.0.0 if you prefer.

Deicyde

The follow-up regression covers the missing platform boundary. Four target-resolution tests pass locally; Intel macOS resolves wheel-only below 49, while arm64 macOS and Linux remain on 49 or newer.

#56 constrained cryptography below 49 on Intel Macs, which publish no wheel for 49 or later. Every other platform stayed on 50.0.0 only because uv carried main's locked version forward as a preference; pyproject.toml did not say so. A fresh `uv lock`, or a routine `uv lock --upgrade`, resolves one version for all platforms, and the only one Intel Macs accept is 48.x. Two of #56's tests then fail with no pointer to the cause, and relaxing them would leave every platform without the fixes in 49 and 50 (CVE-2026-69247, CVE-2026-69248, CVE-2026-69249). Add the complementary constraint, cryptography>=49 outside Intel Macs, so the split is declared instead of inherited. A fresh lock now resolves 48.0.1 on Intel macOS and 50.0.2 elsewhere, and an upgrade keeps the split. The new test checks that pyproject.toml alone bounds both sides; it fails on main for macOS arm64, Linux x86_64 and aarch64, and Windows. Also from the #56 review: - Relock with uv 0.12.1, the version CI pins. #56's lock was written by uv 0.12.22, which records revision 5 where 0.12.1 writes 3, so that line would flip in unrelated PRs. No package version changes. - Run the tests' uv commands with the interpreter running pytest. From an unactivated venv with no other Python 3.10+ on PATH, all four tests failed offline, or uv downloaded a managed Python first.

Main brings PR #15 (scale roadmap graph traversal: iterative traversals in graph.py, graph_views.py, runtime.py, status.py and render.py, a containment index built once per view call that refuses hand-built containment cycles, and tests/test_graph_scale.py) and PR #56 (a uv constraint keeping cryptography below 49 on Intel Macs, which have no wheels past 48, the matching uv.lock entries, and tests/test_lock_platforms.py). render.py: the only conflict, in _book_page_order. #15 replaced the recursive visit() with a pending stack that pushes each page's linked sources in reverse, so pages come out in the same depth-first order without recursion. The stack reads every source from the publication snapshot (source not in snapshot.files, snapshot.text(source)) rather than from disk. The merge keeps #15's loop and the stack's snapshot reads, with continue in place of the old early return. Nothing else in _book_page_order changed on either side; the link moving, page checks, path guard and static-file rules elsewhere in render.py merged without conflict. Tests: #15's test_book_order_handles_a_1200_page_link_chain called _book_page_order without the snapshot argument the stack added; it now captures the pages it wrote into a BlueprintSnapshot and passes that, so it still walks the 1200-page chain the way render does. pyproject.toml, uv.lock, graph.py and the rest merged without conflict.

F1: test_intel_macos_resolves_without_source_builds fails at 346cfad, so CI on #75 turns red once the branch is pushed. The test resolves the committed lock for x86_64 macOS with --no-build, and uv refuses because cmarkgfm==2025.10.22 has no binary distribution there. No cmarkgfm release after 2024.1.14 has an Intel-macOS wheel, and 2024.1.14 has no wheel for Python 3.13 or later on any platform. No release has an Intel-macOS wheel for 3.13, so pinning an older one trades the Intel build for a source build on 3.13 everywhere. Excluding cmarkgfm on Intel Macs with a marker is no better: readback.py imports it at module level, and the CLI imports readback, so those machines would lose the GitHub renderer that read-back checks compare against. An Intel Mac now builds cmarkgfm from its sdist, and the test allows that build and no other: it passes --no-build-package for every other package in uv.lock, so a cryptography release without Intel wheels still fails it, which is the regression it was written for (#56). A second test fails once cmarkgfm ships an Intel-macOS wheel again, so the exemption goes when it stops being needed. The README lists the Xcode Command Line Tools as the Intel-Mac prerequisite, and the pyproject comment points at the test. Checked with uv 0.11.29 and 0.12.1 on Python 3.10 and 3.13. With the Intel-Mac cryptography constraint removed from pyproject.toml, the first test fails on cryptography 50.0.2. With cmarkgfm 2024.1.14 locked, the second test fails on Python 3.12, which has an Intel wheel, and passes on 3.13, which has none. Built from its sdist for x86_64 CPython 3.13 under Rosetta, cmarkgfm 2025.10.22 renders a set of samples byte for byte like the arm64 wheel.

meta-cla Bot added the CLA Signed This label is managed by the Meta Open Source bot. label Oct 2, 2026

Deicyde reviewed Oct 2, 2026

View reviewed changes

Deicyde added the awaiting author Review is complete and author action is required label Oct 2, 2026

Deicyde mentioned this pull request Oct 2, 2026

Verify installed plugin provenance #16

Closed

Deicyde removed the awaiting author Review is complete and author action is required label Oct 2, 2026

Deicyde approved these changes Oct 2, 2026

View reviewed changes

Deicyde added the review: ready Review complete with no known merge blockers label Oct 2, 2026

Deicyde merged commit 80fa754 into facebookresearch:main Oct 2, 2026
5 checks passed

Deicyde mentioned this pull request Oct 2, 2026

Bound cryptography on both sides of the Intel Mac split #57

Merged

Deicyde mentioned this pull request Oct 3, 2026

Add verified statement-review bundles #75

Draft

Navigation Menu

Repository navigation

Constrain cryptography below 49 on Intel Macs - #56

Constrain cryptography below 49 on Intel Macs#56
Deicyde merged 2 commits into
facebookresearch:mainfrom
Paul-Antoine-Bonin:fix/intel-mac-cryptography

Paul-Antoine-Bonin commented Oct 2, 2026

Uh oh!

Deicyde left a comment

Uh oh!

Deicyde commented Oct 2, 2026

Uh oh!

Paul-Antoine-Bonin commented Oct 2, 2026

Uh oh!

Deicyde left a comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

Paul-Antoine-Bonin commented Oct 2, 2026

Uh oh!

Deicyde left a comment

Choose a reason for hiding this comment

Uh oh!

Deicyde commented Oct 2, 2026

Uh oh!

Paul-Antoine-Bonin commented Oct 2, 2026

Uh oh!

Deicyde left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants