GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | |||||||||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | |||||||||||||
GeezerVison is showing github.com — Fix vendored npm VEX beside a file: dir copy (#1511) by mikolalysenko · Pull Request #1513 · SocketDev/socket-patch Conversation
|
| Issue | Test | Without fix | With fix |
|---|---|---|---|
| #1511 discovery (hosted and vendored wiring; named and folder-named source; controls for another version and a workspace-member namesake) | socket-patch-core vex::discover::npm::tests::a_file_directory_link_copy_of_the_same_release_is_not_attested |
fails (1 ref attested) | passes |
#1511 vendored vendor --vex, standalone vex, vendor --check |
socket-patch-cli --test in_process_vendor vendor_npm_file_directory_copy_is_not_attested |
fails: exit 0, "vex":{"statements":1} (the issue's exact symptom) |
passes |
file: directory's own source entry vendor_workspace_member_skipped. That label comes from npm vendored refuses a registry package with vendor_workspace_member whenever a local file: directory (or workspace member) has the same name@version, and the hosted→vendored takeover then un-hosts it, leaving it unpatched #688 and is documented in the contract's error-code table, and namesake_local_directory_does_not_block_registry_copies pins it. Renaming it to a loud vendor_non_registry_entry_skipped is a contract change, so I've left it as a possible follow-up. The run's own --vex warning and vendor --check now name the unpatched copy, so the outcome is no longer silent./code-review high flagged a scoped (@scope/name) folder-name case with no test. That branch of npm_link_source_identity is unchanged code from Fix npm file: copy attested by in-run VEX (#1481) #1482.cargo fmt --all -- --check: clean. cargo clippy --workspace --all-features -- -D warnings: clean.cargo test --workspace --all-features (run in chunks because of the sandbox's disk allowance): every suite passes except 10 write-failure tests that rely on read-only permissions (relax_loop_must_not_traverse_symlinked_root, an_unremovable_hidden_lock_keeps_every_store_entry, wire_write_failure_*, wire_failure_rolls_back_*, *_state_write_failure_*, partial_lockfile_write_failure_*, redirect_json_mode_write_failures_*, scan_redirect_vlt_heal_invalidation_failure_warns). The sandbox runs as root, which bypasses those permissions. The tests are unrelated to this diff, and CI runs them as a non-root user.e2e_vendor_npm_build and e2e_redirect_npm_build with --include-ignored on real npm 10.9.4: 36 and 43 passed./code-review high ran on the diff. Fixed from it: the vendor --check false "wiring missing" diagnosis, the link lookup gated to file: entries, the vacuous in-run VEX assertion, the missing workspace-member control, and the split name derivation. Not fixed, with reasons under "Not changed".npm/, pypi/ and gem/ only dispatch to the binary.🤖 Generated with Claude Code
Generated by Claude Code
Sorry, something went wrong.
There was an error while loading. Please reload this page.
Assisted-by: Claude Code:claude-opus-5-5
Vendored `scan --vex`, a standalone `vex` and `vendor --check` read the npm lock through discovery, which skipped a `file:` directory dependency: npm records it as a link entry with no version, so discovery never saw that it holds the patched release. VEX then said `not_affected` while that workspace member loaded the unpatched directory. Discovery now resolves such a link to its source directory's entry, as the hosted rewriter does since #1482, and withholds the reference with `patched_ref_unattributable`. The lookup moves to vendor::npm_origin so both readers share it. Fixes #1511 Assisted-by: Claude Code:claude-opus-5-5
With the #1511 fix, `vendor --check` on a project whose vendored npm package also installs from a `file:` directory failed with "wiring missing: no lockfile or config references ... re-run socket-patch vendor". The lock does reference the artifact, and re-vendoring cannot reach that copy, so the advice looped. The same held for a bundled, git, url or `file:` tarball copy. The check now reports `copy unpatched:` with the lock entry that installs the unpatched copy, and says to depend on the registry release there instead. Discovery's link lookup is also limited to entries npm installs from a `file:` spec, as in the hosted rewriter, and the regression tests gain a workspace-member control and assert the in-run VEX warning. Refs #1511 Assisted-by: Claude Code:claude-opus-5-5
|
BugBot review Generated by Claude Code |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 7b7f58c. Configure here.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
Vendored npmvex and scan --mode vendored --vex attest not_affected beside a file: directory copy of the patched name@version, which npm installs unpatched
There was an error while loading. Please reload this page.