Merge remote-tracking branch 'origin/main' into agent/fix-requirements-pep440-pin-match

Author: claude

.github/workflows/ci.yml

@@ -261,24 +261,47 @@ jobs:
           cache: false
 
       - name: Install vexctl
-        # `go install` puts the binary in $(go env GOPATH)/bin; surface
-        # that path to subsequent steps so `Command::new("vexctl")` in
-        # the test resolves. Pinned to a tagged release rather than
-        # @latest for reproducibility.
+        # Linux / Windows: the v0.3.0 release binary, checked against the
+        # sha256 pinned here (from the release's vexctl_checksums.txt).
+        # Compiling it took ~80s on ubuntu and ~180s on windows, the
+        # slowest job in this workflow.
         #
-        # Retried: the install compiles sigstore/cosign, whose module
-        # verification reads dozens of sum.golang.org checksum tiles, and
-        # transient INTERNAL_ERROR stream resets there have failed this
-        # step on otherwise-green runs. The backoff rides out short
-        # resets; a persistent outage still fails loudly on the last
-        # attempt. Follow-up option if this recurs: install the pinned
-        # release BINARY (sha256-pinned) instead of compiling, which
-        # sidesteps module verification and drops ~100s of compile time per
-        # leg.
+        # macOS still compiles: the release's darwin binaries are built
+        # with go1.22.7 and have no LC_UUID, so the runner's dyld refuses
+        # them (see the Go step above). The compile is retried: it builds
+        # sigstore/cosign, whose module verification reads dozens of
+        # sum.golang.org checksum tiles, and transient INTERNAL_ERROR
+        # stream resets there have failed this step on otherwise-green
+        # runs. The backoff rides out short resets; a persistent outage
+        # still fails loudly on the last attempt.
+        #
+        # Either way the binary's directory goes on PATH so
+        # `Command::new("vexctl")` in the tests resolves.
         shell: bash
+        env:
+          VEXCTL_VERSION: v0.3.0
+          VEXCTL_SHA256_LINUX_AMD64: cd7f8b57d20642166ed4eb3dd1fd849bbb30bbd7c5b9f5b0316b6003b57ceaba
+          VEXCTL_SHA256_WINDOWS_AMD64: 346fb3104b656fe1a407cbae88ea29a636b36f4569ec58a5a8dadca7343993ed
         run: |
+          set -euo pipefail
+          case "$RUNNER_OS" in
+            Linux) asset=vexctl-linux-amd64 bin=vexctl sha="$VEXCTL_SHA256_LINUX_AMD64" ;;
+            Windows) asset=vexctl-windows-amd64.exe bin=vexctl.exe sha="$VEXCTL_SHA256_WINDOWS_AMD64" ;;
+            *) asset='' ;;
+          esac
+          if [ -n "$asset" ]; then
+            dir="$RUNNER_TEMP/vexctl-bin"
+            mkdir -p "$dir"
+            curl -fsSL --retry 5 --retry-all-errors -o "$dir/$bin" \
+              "https://github.com/openvex/vexctl/releases/download/$VEXCTL_VERSION/$asset"
+            echo "$sha  $dir/$bin" | sha256sum -c -
+            chmod +x "$dir/$bin"
+            "$dir/$bin" version
+            echo "$dir" >> "$GITHUB_PATH"
+            exit 0
+          fi
           for attempt in 1 2 3 4 5; do
-            if go install github.com/openvex/vexctl@v0.3.0; then
+            if go install "github.com/openvex/vexctl@$VEXCTL_VERSION"; then
               break
             fi
             if [ "$attempt" = 5 ]; then

CHANGELOG.md

@@ -102,6 +102,15 @@ limits, and required install commands.
 
 ### Fixed
 
+- Agent-mode PyPI `apply` patches every installed copy of a release, not just
+  the first one found. A Pipenv project with both a WORKON_HOME venv and a
+  `./.venv`, or a global install with the same release in the user site and a
+  system dir, no longer keeps the copy Python imports unpatched while `vex`
+  attests it (#529, #501).
+- Gem hosted and vendored modes wire only the manifest Bundler loads. A `gems.rb`
+  twin or a `BUNDLE_GEMFILE` setting (environment or `.bundle/config`) no longer
+  leads to an edit of an ignored `Gemfile` that reports success and attests an
+  unpatched gem; unsupported layouts are refused before any write (#341, #390).
 - **npm dependencies installed from git, a URL or `file:` are no longer
   reported patched.** npm installs such a dependency from the dependent's
   spec (`github:user/repo`, `https://…/x.tgz`, `file:…`) and ignores the
@@ -148,6 +157,9 @@ limits, and required install commands.
 - Python rewrites preserve supported markers, groups, extras, source metadata, and
   integrity pins. Relocks, out-of-tree environments, and lock-only VEX are handled
   consistently with each installer's supported behavior.
+- Hosted Pipenv scans read the `Pipfile`, so a conflicting `Pipfile.lock` entry
+  refuses the patch project-wide instead of half-redirecting a sibling
+  `requirements.txt` (#333).
 - Vendoring reuses valid committed artifacts during service outages. Updates do
   not build from a previous patch's modified bytes. Verified service artifacts
   keep their identity; integrity failures do not fall through to a local rebuild.
@@ -162,6 +174,27 @@ limits, and required install commands.
 - Transient apply locks are removed on normal command exit; no-op scans and full
   reversal avoid leaving unused `.socket/` state. Terminal output, telemetry
   timeouts, and update-check handling are more consistent.
+- Agent mode finds transitive npm packages in npm's linked store
+  (`install-strategy=linked`, `node_modules/.store`) and in a relocated pnpm
+  `virtualStoreDir`, instead of reporting them `package_not_installed` (#359,
+  #362). A store outside the project, such as pnpm's global virtual store, is
+  shared with other projects and is still not patched in place.
+- npm locks keep their own layout when edited. `scan --mode hosted`,
+  `scan --mode vendored`, `rollback` and `vendor --revert`
+  re-serialized `package-lock.json` / `npm-shrinkwrap.json` with LF line
+  endings (and, in hosted mode, a fixed 2-space indent), so a CRLF or
+  tab-indented lock got a whole-file diff and the undo did not restore its
+  bytes. A lock with a UTF-8 BOM, which npm installs from, was skipped as
+  unparseable (hosted) or refused as `vendor_lockfile_version_unsupported`
+  (vendored). The lock now keeps its BOM, indent and line endings, and the
+  undo is byte-exact (#324).
+- `vendor` under `--global` / `--global-prefix` (or `SOCKET_GLOBAL` /
+  `SOCKET_GLOBAL_PREFIX`) is now a usage error (exit 2,
+  `global_scope_unsupported`), like `scan` and `get` with `--mode vendored`.
+  Run inside a project, `vendor -g` vendored the manifest's records into that
+  project and rewired its lockfile, and `vendor --revert -g` unwound the
+  project's vendoring, so its next frozen install was silently unpatched.
+  Global installs have no project lockfile to vendor into (#498).
 
 ### Maintenance