fix(vendor): verify the extracted tree after a service-download, not just the archive bytes

[Mikola Lysenko (mikolalysenko)]

Summary

The extract-into-dir service-download paths (composer, cargo, golang, gem) verified only the downloaded archive's sha512 SRI, then reported success synthesized from record.files alone — they never checked that the patched files actually landed at their recorded paths on disk. This adds a post-extraction disk verification so a wrong internal layout fails closed (fallback under auto, hard-fail under --vendor-source=service) instead of shipping an empty/misplaced copy with vendor exiting 0.

The bug

extract_zip(..., strip_first=true) (and the golang/cargo/gem equivalents) assume the archive has exactly one wrapper directory. A prebuilt dist zip whose layout differs — an extra wrapper (outer/pkg-<sha>/src/… → single strip leaves pkg-<sha>/src/…) or a root-level src/… (single strip over-strips to LoggerInterface.php) — extracts "successfully" with every file at the wrong path. The Used arm then maps to already_patched_result(purl, &copy_dir, &record.files), which builds a success result from the record keys without reading copy_dir. Net: vendor --json exits 0, envelope status:success/failed:0, and the copy dir is missing its patched files. Archive-bytes SRI verification (fetch_verified_archive) can't catch this — a self-consistent archive with the wrong internal shape passes it.

This is the root fail-open behind depscan's flaky 94_socket-patch-vendor-composer e2e (run 29040958337): the CLI reported success and the test tripped one line later on a bare ENOENT.

Fix

After extraction, each backend calls the existing shared copy_matches_after_hashes(copy_dir, &record.files) and, on mismatch, routes through its own miss closure:

• composer / cargo: verify before the success return; remove the bad copy.
• golang: verify before wiring the consumer's go.mod (so nothing points at a bad copy).
• gem: verify after the stub gemspec is written (the stub isn't in record.files, so it isn't part of the check).

auto → warn vendor_prebuilt_layout_mismatch + fall back to the local build; --vendor-source=service → hard-fail (no silent wrong copy). npm/pypi are intentionally untouched — they persist a single integrity-verified packed artifact (.tgz/.whl), not an extracted tree, so there's no layout-strip step to get wrong.

Tests

Two new composer_lock regression tests build a double-wrapper zip that the single-level strip misplaces:

• service_wrong_layout_service_mode_hard_fails: refuses (copy absent at the recorded path) instead of synthesizing success.
• service_wrong_layout_auto_falls_back_to_build: falls back to a correct local build, with the vendor_prebuilt_layout_mismatch warning recorded.

Both were green-exit-empty-copy before the fix. cargo test -p socket-patch-core --lib vendor:: (546 tests) + clippy pass.

Pairs with

depscan PR fix/composer-vendor-e2e-flake, which independently hardens the e2e assertion (a zero-event vendor no longer passes as success) and captures the envelope + on-disk tree on failure, plus makes the patches/view endpoint fail closed on an unreadable blob.

[Jeppe Hasseriis (cenobitedk)]

LGTM, but I'm not an expert in rust, so I might have overlooked important details