GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Cargo VEX: an ignored [patch] Socket pin still attests a transitive crate; bypass remedies name ambiguous or incomplete commands · Issue #2045 · SocketDev/socket-patch

Cargo VEX: an ignored [patch] Socket pin still attests a transitive crate; bypass remedies name ambiguous or incomplete commands #2045

New issue
Copy link
New issue
Copy link
Open
Open
Cargo VEX: an ignored [patch] Socket pin still attests a transitive crate; bypass remedies name ambiguous or incomplete commands#2045
Copy link
Labels
bugSomething isn't workingSomething isn't workingpm:cargoCargoCargo

Description

@mikolalysenko
Mikola Lysenko (mikolalysenko)
opened on Nov 9, 2026
Issue body actions

Follow-ups found while reviewing #2012 (the folded Cargo VEX stack). All three predate #2012 or are remedy text. None of them blocks it.

1. False attestation: an ignored [patch] Socket pin as a transitive crate's only wiring (also on main)

hosted_from_lock (vex/discover/cargo.rs) keeps the Cargo.lock ref whenever any declaration names the lock's socket-patch-<uuid> registry: regs.iter().any(|d| d.registry == reg). It doesn't check d.live. Cargo can ignore a root [patch.crates-io] serde = { registry = "socket-patch-<U>" } entry in two ways:

  • a [patch."https://github.com/rust-lang/crates.io-index"] table replaces [patch.crates-io];
  • a project-config [patch] item redefines the key.

If that ignored entry is the only wiring of a transitive crate, the ref is still attested. Cargo actually re-resolves serde from crates.io.

Reproduced on #2012's head (f1eb764), with a root manifest carrying that [patch.crates-io] pin and a crates.io-URL [patch] table, and a Socket-sourced serde 1.0.1 in the lock:

  • refs: [(pkg:cargo/[email protected], U, Hosted)]
  • unattested: []
  • diagnostics: [patched_ref_invalid] ("cargo ignores that [patch] entry")

The discovery diagnoses the entry as ignored and still attests the ref.

main has the same gate (regs.iter().any(|r| r.as_deref() == Some(reg))) and no [patch] precedence model at all, so it attests this shape too. #2012 didn't introduce it. The fix probably belongs in hosted_from_lock: count only live declarations for the "names this patch's registry" gate, and treat a ref whose only wiring is a dead [patch] pin like a reverted pin (patched_ref_invalid, no ref).

2. Remedy text: ambiguous cargo update -p / cargo tree -i beside the tagged vendored copy

When vex_cargo_patch_bypassed fires on a same-version lock entry, the detail suggests cargo update -p <crate> and cargo tree -i <crate>@<version>. The lock also holds the vendored copy at <version>+socket.<uuid>, and cargo ignores build metadata when matching a package spec. So both commands fail with "specification … is ambiguous". The remedy should print a source-qualified spec, for example registry+https://github.com/rust-lang/crates.io-index#[email protected], or the git/registry source of the offending entry.

3. Remedy text: a stale entry from another registry gets no re-lock advice

The stale-entry check maps a lock source to a DeclSource only for crates.io and git (DeclSource::of_lock_source). Take a copy wired under [patch."https://my-corp.example/index"] (or [patch.my-corp]) with a stale registry+https://my-corp.example/index entry at the patched version. It isn't recognized as stale, so the user is sent to cargo tree -i to look for a declaring dependency that may not exist. Mapping registry+ / sparse+ sources to DeclSource::RegistryIndex(url) would reuse patched_by.

Checked and not an issue: sparse index URLs. #2012 compares sparse+ URLs with one trailing / ignored, and so does cargo. CanonicalUrl::new (src/util/canonical_url.rs) strips a trailing slash for every URL, and skips only the GitHub lower-casing and .git stripping for schemes containing +.

Activity

  1. Mikola Lysenko (mikolalysenko)
    added
    bugSomething isn't workingSomething isn't working
    pm:cargoCargoCargo
    on Nov 9, 2026
  2. Mikola Lysenko (mikolalysenko)
    added a commit that references this issue on Nov 11, 2026

    Attest a hosted Cargo.lock entry only while cargo routes the crate to it

    a5d5b4b
  3. mikolalysenko commented on Nov 11, 2026

    @mikolalysenko
    Mikola Lysenko (mikolalysenko)
    on Nov 11, 2026
    CollaboratorAuthor
    More actions

    [agent] Janitor: partly fixed on main, so this stays open.

    • Item 1 (ignored [patch] pin still attests): fixed by Fix the defects found by the 5.1.0 full review: do no harm, Bundler hosted mode, VEX, monorepo scans #2052 (354ab998, "Attest a hosted Cargo.lock entry only while cargo routes the crate to it"). The lock ref now needs a declaration that routes it: crates/socket-patch-core/src/vex/discover/cargo.rs:972 (regs.iter().any(|d| d.routes(&uuid, &pkg.version)), Decl::routes at :618).
    • Item 2 (ambiguous remedy): still open. The remedy still prints a bare cargo update -p {name} / cargo tree -i {name}@{version} (cargo.rs:1877, :1883).
    • Item 3 (stale entry from another registry): still open. DeclSource::of_lock_source (cargo.rs:550) still maps only crates.io and git+ sources, so registry+/sparse+ entries are never recognized as stale.

    Generated by Claude Code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingSomething isn't workingpm:cargoCargoCargo

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      You are visitor 01402503 — GeezerVison does not store the pages you look up.
      Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.