Hosted Composer vex attests not_affected for an unpatched package when config.vendor-dir is absolute or uses ~/ or $HOME/

[mikolalysenko]

[agent] Found by the scheduled Composer bug-hunt routine (ledger #321).

Summary

Composer accepts an absolute config.vendor-dir and expands ~ and $HOME in it (Platform::expandPath). resolve_local_vendor_dir deliberately refuses an absolute value and does not expand ~ or $HOME. The code comment says such a project "discovers nothing". In practice the package still shows up from composer.lock, but it is classified as lockfile-only / not installed even though Composer installed it. Two silent failures follow from that:

1. Hosted vex falsely attests not_affected. The package is treated as not installed, so vex falls back to "with nothing installed, attests a discovered lockfile reference from its integrity pin". It never hash-checks the real installed copy, which is still unpatched after composer install.
2. Agent scan --mode agent and apply skip the package as package_not_installed and exit 0. Nothing is patched (Fix apply failing when patched deps are skipped (#403) #555's lockfile-only skip firing on a package that is installed).

With the default vendor/, or with a relative vendor-dir, the same flow correctly omits the package from VEX as not_applied (exit 1).

Impact

A signed-off VEX document claims not_affected for a vulnerability whose vulnerable code is the code actually running. That is the worst outcome for vex. A home-relative or absolute vendor-dir is a supported Composer configuration, for example a shared vendor tree outside the checkout or ~/.cache/... in CI.

Repro (Linux, PHP 8.3, main 045d7ec)

This uses a dist-only package from an inline package repo with a file:// zip, plus a mock patch API (batch, view/<uuid>, patches/package granted with sha1 + sha512, and the archive route), the same shape as crates/socket-patch-cli/tests/e2e_redirect_composer_build.rs.

mkdir app && cd app
cat > composer.json <<EOF
{"name":"t/app",
 "repositories":[{"type":"package","package":{"name":"acme/widget","version":"1.0.0",
   "dist":{"type":"zip","url":"file:///abs/dist/widget-1.0.0.zip"}}},{"packagist.org":false}],
 "require":{"acme/widget":"1.0.0"},
 "config":{"vendor-dir":"~/shared-deps"}}          # or "/abs/app/deps", or "$HOME/shared-deps"
EOF
composer install -n                       # installs ~/shared-deps/acme/widget (original bytes)
socket-patch scan --cwd . …               # hosted: table shows [NOT INSTALLED]; rewrites composer.lock
composer install -n                       # Composer 2 keeps the dist-only install, so the copy stays original
grep STATE ~/shared-deps/acme/widget/src/Widget.php   # -> 'original'
socket-patch vex --cwd . --output vex.json …          # exit 0, 1 statement: not_affected  <-- wrong
socket-patch scan --mode agent --json …               # apply: skipped package_not_installed, exit 0, nothing patched

Control (identical project without config.vendor-dir, so the package is in vendor/): vex prints omitting pkg:composer/acme/widget@1.0.0 from VEX: the patched files still hold the original content (not_applied) and exits 1. The agent scan patches it.

Expected vs actual

• Expected: CLI_CONTRACT.md (VEX table, hosted row) says a post-install socket-patch vex "re-proves the lockfile wiring and hash-verifies the installed copy the build consumes". Only "with nothing installed" may it attest from the pin. Here the package is installed, so vex must either verify the real copy or refuse to attest. If socket-patch can't locate it, it should fail closed, not assume "not installed". Likewise, agent apply should not report success for an installed package.
• Actual: not_affected from the lock pin, exit 0. Agent apply skips it with exit 0.

Matrix (2/2 runs per cell)

Composer (PHP 8.3, Linux)	default vendor/ (control)	vendor-dir absolute	vendor-dir: "~/…"	vendor-dir: "$HOME/…"
1.10.28	omitted not_applied (correct)	false not_affected	false not_affected	untested
2.2.30	omitted (correct)	false not_affected	false not_affected	untested
2.10.3	omitted (correct)	false not_affected	false not_affected	false not_affected

Also checked: an absolute COMPOSER_VENDOR_DIR env var is honoured (correct omission). Vendored mode with an absolute vendor-dir passes, because Composer reinstalls from the .socket/vendor path dist. macOS/Windows weren't probed, but this is pure path logic (%APPDATA%-style values hit the same unexpanded branch on Windows).

Suspect code

• crates/socket-patch-core/src/crawlers/composer_crawler.rs:501-520 (resolve_local_vendor_dir): an absolute value is refused (normalize_config_vendor_dir returns None for a leading /), and ~ / $HOME aren't expanded (parse_config_vendor_dir, :466-480). The refusal then flows into the lockfile-only classification instead of failing closed.
• The hosted VEX "not installed, attest from pin" basis in crates/socket-patch-core/src/vex/discover/composer.rs doesn't distinguish "not installed" from "installed somewhere the crawler refused to look".

Related, not duplicates: #463 (same false-attest symptom via Composer 1 installers paths), #439 (user-level vendor-dir), #658 (reinstall hint names vendor/).

[mikolalysenko]

[agent] Triage: p2 (Composer). Confirmed on main 045d7ec. resolve_local_vendor_dir (crates/socket-patch-core/src/crawlers/composer_crawler.rs:501) returns None for an absolute config.vendor-dir because normalize_config_vendor_dir refuses a leading /. parse_config_vendor_dir also leaves ~/$HOME unexpanded on purpose (see its doc comment). So the installed copy is never found, and discovery falls back to treating the package as lockfile-only. Not a duplicate. No open PR touches it.

Shares root cause with #439: resolve_local_vendor_dir models only part of Composer's vendor-dir resolution. #439 is the missing $COMPOSER_HOME/config.json layer and the hard-coded global vendor; this issue is the missing absolute and ~/$HOME handling. Will be fixed together. (#658, the reinstall hints, is a separate code path.)

---

Generated by Claude Code