Skip to content

Decide: should hosted VEX require installed evidence by default instead of attesting from lockfile wiring? #1099

Description

[agent] Filed by the scheduled architecture audit routine (ecosystems and formats). Register: register comment.

Kind: decision. Source: review §6 Q4; 2.2; 6.5; register E46.

Question

When vex finds no installed copy of a hosted-patched package, should it still attest not_affected from the lockfile wiring (a Socket-host reference plus an integrity pin)? Or should that "lockfile basis" become opt-in, so that the default requires installed bytes that verify?

Options

  • A. Keep today's default. The lockfile basis attests whenever no installed copy is found. Keep fixing package-manager quirks one at a time.
  • B. Installed evidence by default, lockfile basis opt-in. Standalone vex attests a hosted purl only when its consumed copies verify. A flag (for example --allow-lockfile-basis, or --evidence wired) restores today's behavior for lock-only CI checkouts. In-run scan --mode hosted --vex keeps its existing in-run exemption for the purls that run confirmed, which is a separate code path.
  • C. Keep the default, but mark it. Attest from the lockfile basis, but say so in the statement: for example "(redirected, not installed)" in the impact statement, or a distinct status_notes. A consumer can then filter it, and the JSON envelope reports a separate count. This could be combined with A or B.

The audit recommends B + C: opt-in wiring evidence, labelled when used. B is user-visible: it changes the vex output on lock-only checkouts and the documented "before installation" behavior in docs/usage.md. That is why this needs an owner decision.

Background (main @ e61a845)

Consequences

  • A: no user-visible change. The false-attestation class stays open-ended, with one bug per package-manager quirk, and E72 / PR Stop VEX attesting over yarn PnP, pnpm bundled and deno.lock copies #1033 keep growing.
  • B:
    • Lock-only CI checkouts stop attesting unless they pass the flag.
    • docs/usage.md ("Before installation, hosted VEX can describe the pinned dependency state") and the CLI_CONTRACT VEX section change, along with the vex e2e suites that assert attestation from the lockfile basis (for example the pinless_hosted_entry_cannot_use_the_lockfile_basis family, which keeps its meaning under the flag).
    • Removal is roughly the lockfile_attested block plus a flag. The integrity_required plumbing stays, because it gates the flag.
  • C: an additive contract change to the statement text. Consumers keyed on the exact impact string need a note in the provenance-marker contract.

Dependencies

Activity

  1. added
    arch-auditFiled by a scheduled architecture audit routine (see the architecture review discussion)
    refactorStructural change: duplicated code or logic, missing abstraction, layering, dead code
    on Oct 8, 2026
  2. added a commit that references this issue on Oct 8, 2026
  3. mikolalysenko commented on Oct 9, 2026

    @mikolalysenko
    CollaboratorAuthor

    v5 triage: P3, not a release blocker. Keep the documented lockfile-based VEX workflow for this release triage. A wholesale installed-evidence default redesign is P3; concrete false claims in ordinary workflows remain separately prioritized.

    This follows the maintainer's release scope: one normally completing CLI instance, prioritizing valid-lockfile patch/install behavior, compatibility, and actionable CLI UX.

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

    agent:needs-humanagent:triagedarch-auditFiled by a scheduled architecture audit routine (see the architecture review discussion)priority:p3refactorStructural change: duplicated code or logic, missing abstraction, layering, dead codeuxCLI commands, help, diagnostics, output consistency, or actionable recovery instructions.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions