pyproject.toml pins:
cryptography==48.0.1; platform_system == 'Darwin' and platform_machine == 'x86_64'
introduced in f52aa44 ("pin cryptography for Intel macOS"). I understand why 48.0.1 specifically: it's the last cryptography release with an Intel-macOS wheel (49.0.0+ ships arm64-only).
The problem is scope leakage: because this is an exact pin rather than a range, and 48.0.1 happens to have wheels for every platform, resolvers that build one lock across all platforms (uv sync --locked in universal mode; Poetry/PDM universal-lock modes likely behave the same) don't fork per-marker when a single version satisfies every branch, they just resolve cryptography to 48.0.1 project-wide. So Linux, Windows, and Apple-Silicon users of any project depending on tidy3d inherit a 2024-era cryptography even though nothing stops them from getting a current, patched one.
Concretely, cryptography<50.0.0 carries GHSA-g6cj-pr64-35w5 (CVE-2026-69247, high) plus two more (CVE-2026-69248/69249). Downstream projects using uv sync --locked currently cannot clear a pip-audit/osv-scanner gate without an explicit ignore, on any platform, because of a constraint that was only meant to apply to Intel macOS. (We hit exactly this in SiEPIC/gds_fdtd#115.)
Suggested fix: give the resolver something to fork on, e.g.
"cryptography==48.0.1; platform_system == 'Darwin' and platform_machine == 'x86_64'",
"cryptography>=44.0.0; not (platform_system == 'Darwin' and platform_machine == 'x86_64')",
(or any non-degenerate range on the complementary branch) so universal resolvers solve two distinct marker groups instead of collapsing to one shared version. That would let every platform except Intel macOS resolve a current cryptography while leaving the Intel-mac constraint exactly as intended.
Separately, it'd help to note in a comment near the pin why 48.0.1 specifically (cryptography dropped Intel-mac wheels at 49.0.0), non-obvious to anyone reading the pyproject cold, and worth revisiting if/when Intel-mac support is deprioritized.
pyproject.toml pins:
cryptography==48.0.1; platform_system == 'Darwin' and platform_machine == 'x86_64'
introduced in f52aa44 ("pin cryptography for Intel macOS"). I understand why 48.0.1 specifically: it's the last cryptography release with an Intel-macOS wheel (49.0.0+ ships arm64-only).
The problem is scope leakage: because this is an exact pin rather than a range, and 48.0.1 happens to have wheels for every platform, resolvers that build one lock across all platforms (uv sync --locked in universal mode; Poetry/PDM universal-lock modes likely behave the same) don't fork per-marker when a single version satisfies every branch, they just resolve cryptography to 48.0.1 project-wide. So Linux, Windows, and Apple-Silicon users of any project depending on tidy3d inherit a 2024-era cryptography even though nothing stops them from getting a current, patched one.
Concretely, cryptography<50.0.0 carries GHSA-g6cj-pr64-35w5 (CVE-2026-69247, high) plus two more (CVE-2026-69248/69249). Downstream projects using uv sync --locked currently cannot clear a pip-audit/osv-scanner gate without an explicit ignore, on any platform, because of a constraint that was only meant to apply to Intel macOS. (We hit exactly this in SiEPIC/gds_fdtd#115.)
Suggested fix: give the resolver something to fork on, e.g.
"cryptography==48.0.1; platform_system == 'Darwin' and platform_machine == 'x86_64'",
"cryptography>=44.0.0; not (platform_system == 'Darwin' and platform_machine == 'x86_64')",
(or any non-degenerate range on the complementary branch) so universal resolvers solve two distinct marker groups instead of collapsing to one shared version. That would let every platform except Intel macOS resolve a current cryptography while leaving the Intel-mac constraint exactly as intended.
Separately, it'd help to note in a comment near the pin why 48.0.1 specifically (cryptography dropped Intel-mac wheels at 49.0.0), non-obvious to anyone reading the pyproject cold, and worth revisiting if/when Intel-mac support is deprioritized.