GeezerVison

bugbot run

Generated by Claude Code

Labeled Ready for review by the burn-down agent.

• Head: fb3d4183852150c00139b671240b93019ba88655
• CI: 49/49 check runs green (30 success, 19 skipped by path filters)
• Fixed in fb3d418:
  • e2e_redirect_vlt_build rule (c) without a hidden lock still expected the old record-based heal. This PR makes that case undeterminable (copies kept, advisory says run vlt ci), so the e2e now matches the in-process test and checks that vlt ci installs the patched package.
  • Bugbot (medium): the wheel probe read site-packages files with bare std::fs reads, so a FIFO could block the scan. It now uses the regular-file guard, with a FIFO regression test.
• Bugbot: re-reviewed fb3d418, no new issues.
• Reviewer note: stacked on Refuse vendored patches the same way everywhere #2015, which is stacked on Stop downloading vlt artifacts during hosted scans #2013. heal_rule_c_no_record now covers the same scenario as heal_rule_c_no_hidden_lock because patch records are never fetched; consider dropping one of them.
• Slack announcement not sent this run (Slack send tool unavailable); next run retries.

Generated by Claude Code

Final review brief (for the human approver)

What it does: hosted scans stop calling /patches/view, which returned the full patched file contents just to feed checks inside the same scan. In-run --vex now fetches its own records, the same way standalone vex does. The gem stale-install probe compares the sha256 of the cached .gem with the grant's. The Python probe downloads the patched wheel, verifies its sha256 and reads its RECORD. The vlt heal trusts only vlt's hidden lock. Stacked on #2015, so it merges into that branch, not main.

Risk: medium. I found no security problem and nothing that makes the probes warn wrongly. The risk is in the Python probe: it now judges an installed copy only when its WHEEL tags and dist-info name exactly match the first patched wheel for that patch. Where they don't, a stale venv goes unwarned with no signal (see the open questions).

Look here

• wheel_record.rs:40-50: checks the sha256 before it parses anything. Downloads are capped at 256MB and RECORD/WHEEL reads at 16MB. Nothing is extracted. RECORD paths go through is_safe_relative_subpath.
• wheel_record.rs:134-171:`` the tag gate.
• python.rs:91-110:``` how the override is chosen and the --offline skip.
• hosted.rs:387-407:```` any cached .gem whose sha isn't a patched one now warns as stale.
• vlt_heal.rs:258-286:````` with no readable hidden lock the result is now Undeterminable (it used to be `Healthy`), and the in-run VEX drops it. That errs on the safe side.

Verified: I read the PR's own diff (42843ef..fb3d4183852150c00139b671240b93019ba88655, 31 files). No view calls remain on the scan, memory-engine or Node paths. --offline and --dry-run are honoured. CRLF in RECORD is handled. CHANGELOG.md is untouched and there is no debug leftover. Ran locally: wheel_record unit tests (5), CLI stale (23), in_process_redirect_poetry and e2e_redirect_gem_stale_install, all passing. The poetry test depends on the served wheel, so it exercises the new probe. CI: 30 passed and 19 skipped by path filter (49 checks). Bugbot: passing, and its one thread is resolved.

Changes I made: none.

Open questions / nits (none block merging)

1. When a patch ships several platform wheels, or the patched wheel changes its dist-info name or tags (PyYAML vs pyyaml, py2.py3 → py3), the probe never judges the installed copy. Try every matching .whl override? This could be a follow-up.
2. Every re-scan downloads the whole patched wheel again for each pypi candidate that has an installed copy and no local record. That costs about what the old view fetch did.
3. No test covers the --offline skip of the wheel probe, or a gem with no .gem under <home>/cache (git or path sources).
4. Nit: hosted.rs:974-976 still says "patch records (fetched below)", but that fetch is gone.

Auto-merge is not armed. This PR targets #2015's branch, which has no review rule, so arming it would merge it immediately. Approve and merge it after #2015, or retarget it to main once #2013 and #2015 land.

Generated by Claude Code

bugbot run

Generated by Claude Code

Re-labeled Ready for review by the burn-down agent after resolving merge conflicts.

• Head: 4298af6
• Conflicts: main squash-merged this branch's stacked base commits as Stop downloading vlt artifacts during hosted scans #2013 and Refuse vendored patches the same way everywhere #2015, so the merge conflicted in the vlt heal code and tests. The merge (1c97b7f) takes main and re-applies only this PR's own two commits (9bcb4c5, fb3d418), which apply cleanly on top. A follow-up commit drops the Mock/method/path wiremock imports that became unused once the record-fetch-failure test went away.
• CI: 50/50 check runs settled green (31 success, 19 skipped)
• Bugbot: reviewed 4298af6, no findings
• Locally: cargo test -p socket-patch-core --lib and the in_process_redirect / hosted_memory_engine tests pass, except 7 chmod-based write-failure tests that cannot fail as root in the agent container (CI runs them green).
• Reviewer note: the diff against main is now only the patch-view removal and the wheel probe change. The vlt rule (c) heal now reports "undeterminable" when there is no hidden lock, rather than using a record.
• Slack announcement could not be sent from this run (no Slack send tool available).

Generated by Claude Code

Final reviewer: blocked on an open review thread, needs an owner decision (agent:needs-human). Head 4298af60.

The review thread on hosted.rs:405 is unresolved and has no reply. I checked it against the head: when there is no agent-mode record and no <home>/cache/<leaf>.gem, the gem probe (hosted.rs:395-405) returns InstalledRecordJudgment::default(), which means "not stale". On main the fetched patch view's afterHash judged that case. The thread says the PyPI path has the same gap (an sdist pin, or a failed wheel download or sha256 check). It also says in-run VEX then attests the purl through assume_applied.

Question for the owner: when the archive or wheel evidence is missing or can't be fetched, which should the scan do?

1. Fall back to fetching the patch-view record for that purl only. This keeps the old safety, but it puts back some of the fetches this PR removes.
2. Treat the purl as unjudgeable. Add it to known_stale or drop it from assume_applied, so VEX doesn't attest it. No fetch, but it may give false "stale" warnings on images that prune caches.

CI is green (31/31 non-skipped) and Bugbot is clean on this head, so this thread is the only thing blocking it. I haven't posted a review brief.

Generated by Claude Code

Burn-down agent: merged main (568e376) to clear the conflict in the vlt_heal.rs imports. Kept main's crate::origin::hosted_patch_uuid and dropped the patch-view imports this PR removes. Main's two new go-workspace tests in vex_sources.rs now also pass hosted_uuids: Vec::new(). New head 3130bbd; vex_sources tests pass locally. Removed Ready for review until CI is green; the agent:needs-human question is still open.

Generated by Claude Code

Final reviewer (head 3130bbd): approved and CI green. The unresolved thread on hosted.rs:405 is the only thing keeping this out of the merge queue, because the ruleset requires every thread to be resolved.

The owner question from the Nov 7 comment is still unanswered. When gem or wheel evidence is missing or can't be fetched, should the scan (1) fetch that purl's patch-view record, or (2) treat the purl as unjudgeable (known_stale / drop it from assume_applied)? agent:needs-human was removed today without an answer on the PR, so I haven't picked one. Reply with 1 or 2 and the next agent run will implement it, resolve the thread and enqueue the PR. It stays approved.

Generated by Claude Code

Owner decision implemented (head 6259cb3). When the gem archive or Python wheel evidence is missing, can't be fetched, or can't judge the installed copy, the stale-install probe fetches that purl's /patches/view record and judges the copy from it. If that fetch also fails, or under --offline, the copy is withheld: it is dropped from assume_applied, and in-run --vex omits it as stale_install_unverified, even with --vex-no-verify. The normal path still makes no view request.

• Merged main (Read and plan pnpm locks through one core (lock-model 2) #2009, Cargo VEX: read member manifests, match liveness by origin, withhold mixed and vendored bypasses #2012, Never patch a pnpm, yarn or vlt dependency the user patched #2018). The one conflict was the warning list in hosted.rs: I kept main's user-patch warnings and dropped the record warnings this PR removes.
• vlt was already fail-closed (an undeterminable target goes to stale_purls), so it is unchanged. The in-memory engine runs no stale probe, so fetchPatch stays ignored.
• /code-review high:
  • Fixed: a stale gem dir now marks every platform variant stale. Before, the qualifier-insensitive VEX exemption could re-exempt it.
  • Declined: a copy judged with no file-level evidence stays "not stale" (main's record semantics: missing files are never evidence). Gem stale purls stay out of known_stale (pre-existing, documented design). Sequential and duplicate view fetches only happen on the fallback path, and both sides fail closed. The fetch still happens when a variant is already stale, because another variant can still prove the dir patched. The VEX helper refactor has different semantics.
• The hosted.rs:405 thread is replied to and resolved. The PR body is trimmed and updated with the decision.

Generated by Claude Code