chore(deps): drive python-sdk to zero known vulnerabilities in both ecosystems, pin Yarn 4, enforce release-age gate - #59

Drives this repo to zero known vulnerabilities across both ecosystems, verified by auditing every resolved package version against OSV (which carries the same GHSA data Dependabot uses) rather than only the alerts Dependabot chose to surface.

Counts are OSV records, not distinct vulnerabilities. OSV carries GHSA and PYSEC entries separately, so pytest's single CVE-2025-71176 appears as 2 records (GHSA-6w46-j5rx-g56g + PYSEC-2026-1845) where GHSA alone returns 1. Read the Python rows as one vulnerability if you are reconciling against Dependabot.

Nothing here reaches the published artifact. httpx is still the only runtime dependency; the wheel target is packages = ["src/convert_sdk"] and the sdist excludes tests, scripts, package.json, release.config.mjs, .yarnrc.yml and yarn.lock.

Four commits — the fourth applies the blocking finding from review.

1. chore(deps) — clear the npm alerts

All 8 open Dependabot alerts (4 high, 4 medium; no critical was open). Three of the four highs were reachable inside the existing semver ranges. The fourth — sigstore GHSA-52v5-jr5w-gjxr, where certificateOIDs verification constraints are silently dropped and never enforced — needs sigstore >= 4.1.1, and that only arrives through a major bump of the chain that pulls it in:

semantic-release 24.2.9 -> 25.0.9
  @semantic-release/npm 12.0.2 -> 13.1.5
    npm 10.9.8 -> 11.19.0
      libnpmpublish 10 -> 11.2.0  }-> sigstore ^3.0.0 -> ^4.0.0  (4.1.1)
      pacote        19 -> 21.5.1  }   @sigstore/core 2.0.0 -> 3.2.1
      tar 7.5.16 -> 7.5.22

@semantic-release/github moves to ^12 because that is what semantic-release 25 depends on. Leaving it at ^11 would hoist the older copy to the project root, where semantic-release resolves plugins from — so the root copy would shadow the one core installed.

The OSV sweep also clears 7 advisories Dependabot had auto-dismissed and never showed as open — 4 more on tar (including a critical), 2 more on brace-expansion, 1 more on js-yaml. main carries 15 advisories in total; this branch carries none.

Node floor. semantic-release 25 and @semantic-release/github 12 require ^22.14.0 || >= 24.10.0. release.yml installs lts/* on both jobs — currently Node 24.19.0, satisfied today, and every future LTS line stays above the floor.

2. chore(ci) — pin Yarn 4, enforce a 3-day minimum release age

Same fix as convertcom/php-sdk#60, applied here.

The intent was to add the npmMinimalAgeGate that javascript-sdk and php-sdk carry. Checking whether it would actually fire turned up why it wouldn't. release.yml already runs corepack enable — that is not enough on its own. With no packageManager field in package.json, corepack has nothing to resolve, falls through to its own default (Yarn 1.22.22) and downloads it. From the last real release run (30637880488, 2026-07-31):

! Corepack is about to download .../yarn-1.22.22.tgz
yarn install v1.22.22
[1/4] Resolving packages...
warning Workspaces can only be enabled in private projects.
success Saved lockfile.

Three consequences, all live until this PR:

1. The committed yarn.lock was never used. Classic Yarn cannot read a __metadata: version: 10 lockfile, so it re-resolved every release from the package.json semver ranges against whatever the registry served at that moment. success Saved lockfile. is Yarn 1 writing its own, which is then discarded.
2. --immutable was a silent no-op. Classic spells it --frozen-lockfile, does not error on the unknown flag, and saved a lockfile regardless.
3. .yarnrc.yml was never read. nodeLinker: node-modules did nothing, and an age gate added there would have done nothing either.

So the packageManager pin is what makes the gate exist, not a nicety alongside it. Written with corepack use yarn@4.18.0, never by hand. The version is not a free choice: 4.18.0 wrote the lockfile in commit 1, and Yarn 4.10.3 rejects that same lockfile as YN0028: The lockfile would have been modified by this install — the pin has to match the writer. Same pin and hash as php-sdk#60.

npmMinimalAgeGate: 4320 (3 days) is the same value javascript-sdk carries (php-sdk gets it when #60 merges). No npmPreapprovedPackages — unlike javascript-sdk, this project has zero @convertcom/* packages in package.json or yarn.lock (the SDK ships via PyPI; the only Node packages here are release tooling), so an exemption list would be dead config. Yarn 4.18 already defaults the gate to 1440 (1 day), so this raises it to the house value rather than introducing the concept.

3. chore(deps) — patch pytest CVE-2025-71176

Dependabot reports no pip alerts for this repo. The OSV sweep of the resolved dev tree finds one anyway: GHSA-6w46-j5rx-g56g / PYSEC-2026-1845 / CVE-2025-71176 — pytest's insecure temporary directory. /tmp/pytest-of-{user} is predictable, so a local user can pre-create or symlink it to cause a denial of service or possibly gain privileges. MODERATE, AV:L.

The advisory range is introduced: 0 → fixed: 9.0.3 — every pytest release before 9.0.3 is affected. pytest 9 requires Python >=3.10 (verified against the PyPI requires-python of every 8.4.x and 9.x release), NFR22 mandates the full CPython 3.9–3.13 matrix, and the SDK's own floor is 3.9. So no single specifier is both patched and installable across the matrix: the existing pytest>=8.4,<8.5 pin was right about the constraint but left all five cells on an affected release.

Split on an environment marker rather than narrowing the matrix:

"pytest>=9.0.3,<10; python_version >= '3.10'",
"pytest>=8.4,<8.5;  python_version < '3.10'",

The py3.9 cell is an irreducible remainder — no upstream release clears it while the SDK supports Python 3.9. It is bounded: pytest is dev-only and never ships, and the vector is local. The only route to a literal zero there is moving the SDK's requires-python floor to 3.10, which is a product decision about who can install the SDK, not a dependency fix — so it is flagged here, not taken. Collapse the two lines into pytest>=9.0.3 if that floor ever moves.

Verification

pytest 8 → 9 is a major bump, so the suite was run rather than assumed. Every command below is the one the workflow itself runs.

• test matrix cell — uv sync --group dev --upgrade then pytest -p no:cacheprovider --cov=convert_sdk --cov-report=term-missing --cov-fail-under=85: 1134 passed, total coverage 96.76%, and the evaluation/ floor holds at 97% against its 95% gate.
• lint + type-check — ruff check src tests scripts demo, check_generated_pyi_header.py, mypy --strict (47 files), mypy --strict typecheck/serving_config_contract.py: all clean.
• bounds-check (lower) — --resolution lowest-direct plus the ci/lower-bounds-overrides.txt httpx pin, --ignore=tests/parity: 920 passed.
• Cold-cache immutable install — node_modules removed and an empty YARN_GLOBAL_FOLDER, so all 418 packages download fresh with the age gate active: yarn install --immutable passes. The real CI shape, not a warm-cache stand-in.
• yarn release:dry-run — loads all four configured plugins, passes verifyConditions for both exec and github (GitHub auth plus push permission), and analyzes commits to "no release". Correct: chore is a non-releasing type in release.config.mjs, so this PR will not cut a version.
• No hardening opt-out was written. Yarn's lockfile migration is known to rewrite .yarnrc.yml with npmMinimalAgeGate: 0, enableScripts: true and approvedGitRepositories: ["**"] when it bumps a legacy lockfile. It did not fire here (no YN0087, the lockfile was already current), and yarn config --json confirms it after the change: gate = 4320 sourced from .yarnrc.yml, enableScripts = false, approvedGitRepositories = [].
• Publish-age sweep — all 122 newly-added lockfile resolutions checked against their npm registry publish time. Zero under the 3-day floor; youngest is semantic-release@25.0.9 at 3.5 days.
• Lockfile format unchanged (__metadata version 10, cacheKey 10c0).

Found while verifying — NOT fixed here

The 15-cell CPython matrix has never run anything but Python 3.13. Every test (py3.x / …) cell and bounds-check (lower) do uv sync --group dev --python <ver> and then a bare uv run pytest. Because .python-version pins 3.13, that bare uv run discards the venv the sync step just built and recreates it at 3.13. Reproduced locally:

$ uv sync --group dev --python 3.9
$ .venv/bin/python -V
Python 3.9.25
$ uv run pytest ...
Using CPython 3.13.13
Removed virtual environment at: .venv
Creating virtual environment at: .venv

and confirmed in the job log of the cell named test (py3.9 / ubuntu-latest): platform linux -- Python 3.13.12. That is why tests/test_packaging.py's bare import tomllib (stdlib only from 3.11) has never failed CI — it fails immediately under a real 3.9 interpreter.

This is left out deliberately. Repairing the matrix makes CI genuinely run 3.9–3.12 for the first time, which turns it red until test_packaging.py and anything else 3.9-incompatible is fixed — real work with its own blast radius that has no business riding inside a security fix. Filed separately.

It does not weaken anything above: since CI actually runs 3.13 everywhere, after commit 3 every cell installs a patched pytest. The 8.4.x fallback only materialises for someone deliberately on 3.9.

Also deliberately not done

• No resolutions override forcing sigstore@4 under libnpmpublish@10 / pacote@19. Those were written against the sigstore 3 API; forcing a major across that boundary would be a guess, not a fix.
• No bump of conventional-changelog-conventionalcommits off ^8. semantic-release 25's commit-analyzer and release-notes-generator still resolve conventional-changelog-writer@^8 and conventional-commits-parser@^6, the same pair as before, so ^8 stays correct and there is no advisory against it.
• No .github/dependabot.yml. This repo has alerts but no update config, which is why these sat open. Worth adding as its own change.
• No lockfile for scripts/js_reference (murmurhash@^2.0.1, currently advisory-free), and no fix for its install instruction, which names a package manager the house rules forbid. Not a vulnerability; separate cleanup.

Review outcome

Reviewed by @usmanabbas7 — verdict approve after one edit, with an independent re-derivation against GHSA (this PR audited OSV), landing on the same main = 6 packages / 15 advisories → branch = 0.

• Finding 1, blocking — fixed in docs: align TESTING.md with the pytest marker split. TESTING.md still said pytest was pinned to >=8.4,<8.5 for Python 3.9, and pointed a future maintainer at collapsing the specifiers that way — which would have reintroduced CVE-2025-71176 on every cell. A repo-wide grep confirms TESTING.md and pyproject.toml were the only two homes for that rationale, so no third copy remains to drift.
• Finding 4, accuracy — fixed above: the advisory counts are OSV records, and the Python figure is one CVE carried as two.
• Finding 6, cosmetic — fixed in the same commit: .yarnrc.yml no longer credits php-sdk for a gate that lands only when build(deps): bump the npm_and_yarn group across 1 directory with 4 updates #60 merges.
• Findings 2, 3, 5 — routed, not bundled. Filed as their own tasks: a release-tooling CI job so yarn.lock, the 4.18.0 pin and the age gate are gated at PR time instead of first exercised by release.yml on main (finding 2 — the strongest of the three, and exactly what would have caught classic Yarn servicing releases without a human reading job logs); converging javascript-sdk off yarn@4.10.3 (3); and the pytest-cov>=5,<6 cap now that the pytest floor moved two majors (5). None changes a resolved version, so none belongs in a security fix.

🤖 Generated with Claude Code