patch-bridge: add allowlist for vendored-pin patterns (Cohort E-3)

[hyperpolymath]

Summary

patch-bridge / cargo machete --fix / any future automated phantom-strip flow needs an allowlist for vendored-pin patterns so it doesn't strip load-bearing build-script-only deps and break TLS / native-lib resolution.

This issue covers Track E Cohort E-3 (vendored-pin allowlist work). Estate tracker: #32.

Allowlist patterns

Never strip — never feature-strip — any of:

Vendored TLS / crypto

• openssl-sys = { ..., features = [..., "vendored", ...] }
• git2 = { ..., features = [..., "vendored-libgit2", ...] }
• git2 = { ..., features = [..., "vendored-openssl", ...] }
• reqwest = { ..., features = [..., "native-tls-vendored", ...] }
• native-tls = { ..., features = [..., "vendored", ...] }
• openssl = { ..., features = [..., "vendored", ...] }
• Any direct openssl-src dep

Build-script-only crates (no use site by design)

These crates are commonly declared in [dependencies] but used purely from build.rs or for their linker side-effects:

• pkg-config
• cc
• bindgen
• cmake
• autocfg
• vcpkg
• winres / embed-resource

Manifest directives

• Any [package] block containing links = "..." (declares a native library link target; the Rust crate is the canonical binding for that native lib and must not be stripped even if not imported)
• Any [build-dependencies] entry — out of scope for cargo machete by default but explicitly out-of-scope for any future estate-wide strip flow.

Affected Track E repos

Confirmed vendored-pin patterns in the 29-repo Cohort E inventory:

• hyperpolymath/vcs-ircd — vext-core/Cargo.toml has openssl-sys = { version = "0.9", features = ["vendored"] } for cross-compile TLS. (See security: 5 CVE advisories in Cargo.lock (bridge triage, Track E) vcs-ircd#36)
• hyperpolymath/hypatia — cli/Cargo.toml has git2 = { ..., features = ["vendored-libgit2", "vendored-openssl"] } for cross-platform CLI distribution. (See security: 1 CVE advisories in Cargo.lock (bridge triage, Track E) hypatia#330)

No other Track E repos surfaced vendored-pin patterns via the gh search code sweep (queries: openssl-sys vendored, vendored-openssl, native-tls vendored, extension="toml" vendored, openssl-src). If additional patterns surface later they should be added inline above and the cohort comment thread updated.

Why this matters

Reachability phantom ≠ safe to remove. Build-script side-effects and vendored linkage produce zero use sites in .rs source by design. A naive cargo machete --fix will:

1. Strip openssl-sys → next build fails to find vendored OpenSSL → native-tls falls back to system libssl-dev → cross-compile breaks.
2. Strip cc / bindgen in a workspace that uses them from a sibling build.rs → workspace builds break inscrutably.
3. Strip the line declaring links = "foo" → another crate's DEP_FOO_* env vars vanish → silent rebuild misbehaviour.

Implementation hooks

Wherever the strip flow lives (TBD — patch-bridge CLI, a future cargo-machete-wrapper, or per-repo .cargo-machete.toml ignores), enforce the allowlist via:

1. .cargo-machete.toml-style ignore lists committed per-repo for the explicit names above, OR
2. A central deny-strip regex in the bridge tool that pattern-matches vendored, links\s*=, and the build-script-only crate names.

Option 2 is preferred because it doesn't require per-repo touchpoints.

Acceptance

• Allowlist mechanism implemented in patch-bridge (or successor tool).
• Regression test: feed a synthetic Cargo.toml containing each of the patterns above; assert all are preserved.
• Estate-wide retest of Cohort E once any future strip flow is wired.

🤖 Filed during Track E Cohort E-3 triage — 2026-05-27