Hosted Maven never re-pins: a superseding patch uuid or a rotated grant token leaves the old wiring in place

[mikolalysenko]

[agent] Filed by Claude Code on behalf of Mikola Lysenko (@mikolalysenko) while adding Maven patch SBOM annotations to depscan. Repro artifacts were produced with real Maven and a stub patch API.

Summary

Once a pom carries <base>-socket.<hexA>, a later hosted run cannot move it forward:

• Superseding patch (the backend now grants uuid B for the same GAV): the literal 3.12.0-socket.4d5e6f70 "matches neither the base nor the suffixed (3.12.0-socket.9a8b7c6d) version". The run warns redirect_maven_dep_version_mismatch, edits nothing, reports redirected: 0, and exits 0.
  • This happens even when .socket/vendor/redirect-state.json records patch A for that purl, so the ledger could prove the suffix is ours.
• Rotated grant token (same uuid, new token path segment in indexUrl): the <id>socket-patch-<uuid></id> guard sees the repository as present. The pin already exists, so pin_landed is false, and the stale token URL is kept. The run reports redirected: 1, edits nothing, and gives no warning.

Impact

• Projects stay pinned to an old patch forever, including when a newer patch fixes an additional CVE or a bad patch. Nothing tells the user except a "mismatch" warning that suggests they hand-edited the version.
• Whether the old-token URL keeps working depends on the server's grant lifetime. If it is revoked, builds break with no CLI remedy short of manual editing.

The gem hosted rewriter fixed the same class in #211 ("hosted grant rotation refreshes the source block in place"). Bun re-pins "a hosted URL left by an earlier grant of the same name@version".

Repro

Stub grant for commons-lang3 3.12.0. Start from the basic golden pom.

run 1: grant uuid A=4d5e6f70-…  -> redirected=1, pom <version>3.12.0-socket.4d5e6f70</version>, repo socket-patch-4d5e6f70-…
run 2: grant uuid B=9a8b7c6d-…  (ledger present)
       -> exit 0, redirected=0, rewrittenFiles=[], warnings=[redirect_maven_dep_version_mismatch:
          "<version>3.12.0-socket.4d5e6f70</version> matches neither the base (3.12.0) nor the suffixed (3.12.0-socket.9a8b7c6d) version"]
       pom unchanged (still A)
run 2b: same as run 2 without .socket/ -> identical result
run 5: grant uuid A, token 77777777-… (was 22222222-…)
       -> exit 0, redirected=1, rewrittenFiles=[], warnings=[]
       pom <url> still .../maven/22222222-3333-4444-8555-666666666666/4d5e6f70-…/maven2

Expected vs actual

• Expected:
  • A literal that parses as <base>-socket.<hex8> for the grant's own base version is our wiring. That holds for any hex8, and certainly when the ledger records it.
  • Such a literal should be re-pinned to the new suffix. The stale socket-patch-<old uuid> repository and checksum lines should be replaced, recorded as edits so rollback can unwind them.
  • A repository whose URL differs from the grant's indexUrl should be refreshed in place.
• Actual: no supersede, no token refresh, and exit 0.

CLI revision

3efdc31d

Suggested fix

• In rewrite_maven_pom, treat split_socket_version(v) == Some((dep.version, _)) as rewritable.
• Replace or remove the old repository block by id.
• Compare the existing repository <url> with ov.index_url.
• Add goldens supersede-new-uuid and token-rotation.

File refs (at 3efdc31)

• crates/socket-patch-core/src/patch/redirect/mod.rs:6122-6136 (mismatch → skip)
• crates/socket-patch-core/src/patch/redirect/mod.rs:6170-6187 (pin_landed guard; <id> presence guard ignores the URL)