socket.yml `ignorePackages` / `packages` and `scan --package` don't PEP 503-normalise PyPI names, so `ignorePackages: ["typing_extensions"]` is silently ignored and the package is patched anyway

[mikolalysenko]

[agent] Found by the scheduled pip / requirements.txt bug-hunt routine (ledger #309).

Summary

The policy package matcher (package_spec_matches) compares PyPI names by lowercasing them only. Every PyPI purl socket-patch builds is PEP 503-canonical (canonicalize_pypi_name: _ / . / - runs become -). So a spec written the way the name appears in requirements.txt, on PyPI's project page or in import (typing_extensions, zope.interface, ruamel.yaml, pkg:pypi/typing_extensions) never matches pkg:pypi/typing-extensions@4.12.2.

Impact:

• Exclusion fails open. patches.ignorePackages: ["typing_extensions"] is dropped silently. The hosted scan rewrites requirements.txt to the Socket build and exits 0. policy.filtered[] is empty and there is no warning, so a team that opted a package out of patching still has it patched.
• Allowlist and --package fail closed, also silently. patches.packages: ["typing_extensions"] and scan --package typing_extensions select nothing (policy_package_not_listed / nothing redirected), with no hint that the spelling is the cause.
• Any PyPI project whose name contains _ or . is affected (typing_extensions, zope.interface, ruamel.yaml, jaraco., backports., …). The matcher is shared by every PyPI package manager. I found and verified it with pip / requirements.txt.

Repro (main 9c43dfc, Linux, pip 26.0 / 24.0, CPython 3.11)

The patch API is a local mock that serves one free patch for pkg:pypi/typing-extensions@4.12.2 (batch, by-package, package grant and the patched wheel), the same shape as crates/socket-patch-cli/tests/hosted_superseding_pypi.rs.

mkdir proj && cd proj && git init -q
python3 -m venv .venv && .venv/bin/pip install typing_extensions==4.12.2
echo 'typing_extensions==4.12.2' > requirements.txt
printf 'version: 2\npatches:\n  ignorePackages: ["typing_extensions"]\n' > socket.yml
VIRTUAL_ENV=$PWD/.venv socket-patch scan --mode hosted --yes --ecosystems pypi --json \
  --api-url $MOCK --patch-server-url $MOCK --org test-org --api-token x
# status: success, redirect.redirected: 1, policy.filtered: []
cat requirements.txt
# typing-extensions @ http://…/patch/pypi/typing-extensions/4.12.2/…/typing_extensions-4.12.2-py3-none-any.whl#sha256=…
python3 -m venv fresh && fresh/bin/pip install -r requirements.txt
fresh/bin/python -c 'import typing_extensions as t; print(t.SOCKET_PATCHED)'   # 1, so the patched build is installed

Results for each spec spelling (fresh project each time; reproduced twice):

Spec	Key	Result
typing-extensions	ignorePackages	filtered (policy_package_ignored), file untouched ✅
typing_extensions	ignorePackages	redirected: 1, filtered: [] ❌
Typing_Extensions	ignorePackages	redirected: 1 ❌
typing.extensions	ignorePackages	redirected: 1 ❌
pkg:pypi/typing_extensions	ignorePackages	redirected: 1 ❌
typing_extensions	packages (allowlist)	nothing patched, policy_package_not_listed ❌
typing_extensions	scan --package	nothing patched, no warning ❌
typing-extensions	scan --package	redirected: 1 ✅
typing_extensions	ignorePackages, --mode agent	policy.filtered: []; the package is handed to apply

You can see the same thing at unit level: package_spec_matches("typing_extensions", "pkg:pypi/typing-extensions@4.12.2") returns false.

Expected vs actual

• Expected: CLI_CONTRACT.md ("Package specs are exactly --package's: a name … or a purl … names compare case-insensitively"). The matcher's own doc comment gives the reason: "PyPI, NuGet and Composer names are case-insensitive". PyPI names are equivalent under PEP 503 normalisation, not just case folding: pip treats typing_extensions, typing-extensions and Typing.Extensions as one project. The "Narrowing never removes … trust boundary" section says a policy only ever removes candidates, so a valid exclusion that silently stops excluding is a policy bypass.
• Actual: only the exact canonical - spelling matches. Every other spelling is dropped without a socket_yml_* warning.

OS × version

OS	pip / Python	Reproduces
Linux	pip 26.0 + 24.0 / CPython 3.11	yes (hosted and agent policy evaluation)
macOS / Windows	—	not probed. The matcher is pure string logic with no OS branch, so I expect the same result

This isn't a regression: socket.yml and --package are new in v5 (unreleased; the latest tag is v4.0.0).

Suspect code

• crates/socket-patch-core/src/policy/mod.rs:744-779 (package_spec_matches): to_lowercase() only. For a pkg:pypi/ purl it should compare canonicalize_pypi_name of both the spec name and the purl name, for both the bare-name and the purl-spec branches.
• The same function backs scan --package (crates/socket-patch-cli/src/commands/scan/mod.rs:1913) and get's policy_bypassed check.
• Related refactor: Move canonicalize_pypi_name and the PEP 508 name scanner out of crawlers and vendor into one PyPI name module #883 (moving canonicalize_pypi_name into a PyPI name module would make it reachable from policy).

[mikolalysenko]

[agent] Triaged: confirmed on main (9c43dfc). package_spec_matches in crates/socket-patch-core/src/policy/mod.rs only calls to_lowercase() on the spec and the purl name, in both the bare-name and the purl-spec branches. PyPI purls are PEP 503-canonical, so typing_extensions, typing.extensions and pkg:pypi/typing_extensions never equal typing-extensions. The same function backs patches.ignorePackages, patches.packages, scan --package and get's policy_bypassed check, so it accounts for every row of the table.

priority:p1 (PyPI). Not a duplicate. #453 is a different get <uuid> early return, and #883 is the related refactor that would put canonicalize_pypi_name within reach of policy. No open or merged PR covers it.

---

Generated by Claude Code

[mikolalysenko]

[agent] Claiming this issue (shared root cause: policy::package_spec_matches case-folds PyPI names instead of PEP 503-canonicalizing them). Branch: agent/fix-policy-pypi-name-normalize. Claim-ID: 2026-10-06T03:20:41Z-c29e03

---

Generated by Claude Code

[mikolalysenko]

[agent] Draft PR: #911

---

Generated by Claude Code