[JarryShaw]

Please follow the guide below

• You will be asked some questions, please read them carefully and answer honestly

• Put an x into all the boxes [ ] relevant to your pull request (like that [x])

• Use Preview tab to see how your pull request will actually look like

• Searched for similar pull requests

• Followed the coding style (make pylint, make mypy, make isort)

• make test passes, and a test case covers the change. Narrow runs only, listed below.

• Added a changelog entry under docs/source/changelog/ and regenerated CHANGELOG.md, if the change is user-visible: N/A — centralised in docs(changelog): shared 1.5.0 changelog — long-lived, merges last (#610, #616, #617, #618, #620) #657

What is the purpose of your pull request?

Tick the commit type your subject line carries.

• fix — corrects a defect
• feat — adds a feature
• perf — changes performance, not behaviour
• refactor — changes neither behaviour nor performance
• test — tests only
• docs — documentation only
• ci — workflows or build tooling
• release — bumps the version or rolls up a distribution
• chore — anything else

---

Description

Closes #1827. This implements option B from the ruling on #1822.

cryptography has shipped no Intel macOS wheel since 49.0.0, so the native osx-64 leg from #1825 would build 50.0.2 from source. That build probably links the runner's Homebrew OpenSSL.

• Requirements: conda/requirements.txt now pins cryptography==48.0.1, the universal2 wheel, with a PEP 508 marker for sys_platform == "darwin" and platform_machine == "x86_64". Every other build keeps 50.0.2. The markers take effect in each leg's own pip download -r conda/requirements.txt step, which runs on its native runner.
• Writer: util/conda_vendor.py keeps the exception in a PLATFORM_PINS table, with the reason as a comment, and the writer emits the marked lines.
• --check: it now also fails when a fixed pin moves, and when the table names a package or platform no build uses. The next Conda Update cannot silently drop the pin.

Verified:

• packaging.markers selects 48.0.1 only on osx-64.
• pip download --only-binary=:all: with each platform's tags resolves the universal2 48.0.1 wheel on Intel macOS and 50.0.2 wheels on linux-64 and osx-arm64, for 3.11–3.15.
• The new tests/project/test_conda_cryptography_pin_1827.py fails on main (8 failed). tests/project gives 981 passed, 1 skipped.

Not verified: no Actions run.

[JarryShaw]

Verdict: GOOD TO GO at b033843a4. A Sonnet cross-review (author: Opus) checked:

• Platform selection: the markers select exactly one cryptography line for every conda target on 3.11–3.15. pip's own download -r with darwin/x86_64 markers saves the 48.0.1 universal2 wheel, and 48.0.1 is the newest release with any Intel macOS wheel.
• Download and build: the download and the build run in the same native job in both conda workflows.
• --check: it fails on ten different mutations of the pin, table or markers, and still flags missing, stale and dead packages.
• Tests: the new tests catch nine further code mutations.
• Dependencies: 48.0.1 and 50.0.2 declare the same dependencies.

Non-blocking: the Intel leg's own pip install -e .[all] into the runner still builds cryptography 50.0.2 from source. That copy is not what gets packaged. The image has Rust and OpenSSL, but no Actions run has confirmed it yet.

[github-actions]

Coverage: 90.05% (unit tier, Python 3.15, b033843a4, Unit Tests run success)

Package	Statements	Missed	Branches	Partial	Cover
pcapkit (top level)	104	2	20	2	96.77%
pcapkit/const	19595	881	2618	867	92.11%
pcapkit/corekit	2462	69	780	35	96.55%
pcapkit/dumpkit	276	3	100	3	98.40%
pcapkit/foundation	2915	164	1016	34	93.59%
pcapkit/interface	138	7	52	5	93.68%
pcapkit/protocols	17408	224	4580	189	98.10%
pcapkit/toolkit	872	177	298	8	77.18%
pcapkit/utilities	512	2	158	4	99.10%
pcapkit/vendor	4407	2342	1010	157	43.27%

Per-file detail: the coverage-html artifact of this run.