[eterceros]

At a glance: before vs. after

flowchart LR
  subgraph BEFORE["❌ Before"]
    direction TB
    b1["crates/pysof/Cargo.lock tracked<br/>pins pyo3 0.24.2"] --> b2["cargo and maturin resolve pysof<br/>against the root Cargo.lock<br/>so the member lock is never read"]
    b2 --> b3["Scanners flag about 34 advisories<br/>in a file no build uses"]
  end
  subgraph AFTER["✅ After"]
    direction TB
    a1["Member lockfile deleted"] --> a2["Root Cargo.lock is the only Rust lock<br/>pyo3 0.29.0, as pysof/Cargo.toml requires"]
    a2 --> a3["maturin sdist ships the root Cargo.lock<br/>and no stale file is left to scan"]
  end

Loading

	Before	After
Tracked Rust lockfiles that cover pysof	2 (Cargo.lock at the root and in crates/pysof)	1 (root Cargo.lock)
pyo3 version in the member lock	0.24.2, which does not satisfy pyo3 >= 0.29	file removed (root lock has 0.29.0)
Lines in crates/pysof/Cargo.lock	4490	0 (file removed)
[tool.maturin] include entries	4, including Cargo.toml	3 (Cargo.toml dropped, see Fix)

Problem

pysof is a member of the root workspace (members = ["crates/*"]), so cargo and maturin resolve its dependencies against the root Cargo.lock. crates/pysof/Cargo.lock was never read by any build. It had gone stale: it pins pyo3 0.24.2, while crates/pysof/Cargo.toml requires pyo3 >= 0.29 and the root lock has 0.29.0. It still showed up in Dependabot, OSV and GitHub security alerts. The CI Security Audit job audits only the root lock, so CI never saw it.

Deleting the file also exposed a latent problem in crates/pysof/pyproject.toml. The [tool.maturin] section listed Cargo.toml in include. Without the member lockfile, that entry collides with the workspace-root Cargo.toml that maturin adds to the sdist, and maturin build --sdist fails. The CI wheel job (ci.yml, "Build pysof wheel (Linux with sdist)") runs exactly that command.

Fix

• Delete crates/pysof/Cargo.lock. Regenerating it would not help, because inside a workspace cargo does not create a member lockfile. This leaves the root Cargo.lock as the single source of truth for Rust dependencies.
• In crates/pysof/pyproject.toml, change include from ["Cargo.toml", "pyproject.toml", "src/**/*", "README.md"] to ["pyproject.toml", "src/**/*", "README.md"]. maturin always ships Cargo.toml in the sdist, so the entry was redundant, and removing it removes the collision.
• crates/pysof/uv.lock (the Python lockfile) is untouched, as the issue asks.

Tests

• Reference check: I searched the repo, excluding target/ and .git, for Cargo.lock references. No script, workflow or doc points at crates/pysof/Cargo.lock. The remaining hits are the root lockfile and unrelated prose.
• sdist build: I checked the issue's pre-merge item with maturin 1.10.1, the version pinned in crates/pysof/uv.lock. The sdist builds and contains the root lockfile as pysof-<ver>/Cargo.lock.
• Not run locally: the full wheel matrix from the CI step uv run maturin build --release --sdist -o dist -i python3.10 … -i python3.14, and maturin develop. Those run in CI on this PR.

Closes #2192

PR auto-generated by claude-agent; fix implemented with Claude Code and validated with the Playwright e2e suite.

[claude]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!