GeezerVison

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

GeezerVison is showing github.com — Fix vendored Hatch running a planted hatch (#613) by mikolalysenko · Pull Request #617 · SocketDev/socket-patch

Conversation

Mikola Lysenko (mikolalysenko) commented Oct 2, 2026 •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link

Copy Markdown

Collaborator

LLM Description written by Claude Code:claude-opus-5-5

Fixes #613

Summary

Vendoring a Hatch project whose environments depend on the patched package no longer runs a hatch executable committed to the scanned repository. The hatch --version probe now resolves hatch on absolute PATH entries only and spawns the resolved path, as every other in-project spawn already does.

Root cause

require_environment_context_support in crates/socket-patch-core/src/vendor/pypi_hatch.rs spawned a bare Command::new("hatch") with current_dir(root). A relative PATH entry (. or an empty component) resolves against the child's cwd, so the scan executed <project>/hatch. This was the last production bare-name spawn in core/CLI. The others go through utils::process::resolve_tool, which skips relative entries.

Change

require_environment_context_support delegates to a new require_environment_context_support_with(root, var), which takes an injected environment reader for tests.
It resolves hatch with resolve_tool_with and spawns it through process::command_for. The cwd, null stdin, kill_on_drop and 10 s timeout are unchanged.
When no hatch is found, the run takes the existing pypi_hatch_unsupported "requires Hatch >=1.2 on PATH" refusal.
Doc touch-up: resolve_tool now lists hatch among the tools it serves.
No wrapper changes are needed (npm/, pypi/, gem/ don't spawn Hatch).

Test evidence

Issue	Regression test	Without fix	With fix
#613	`vendor::pypi_hatch::tests::planted_hatch_in_the_project_is_never_executed`: planted `hatch` in the project, `PATH` = `.`, empty, and `:/nonexistent`. Asserts it never runs and the result is `pypi_hatch_unsupported`	FAILED: `planted hatch ran with PATH="."`	ok
#613	`vendor::pypi_hatch::tests::hatch_on_an_absolute_path_entry_passes_the_version_gate`: a `hatch` on an absolute `PATH` dir is run and passes the >=1.2 gate	ok (control)	ok

Commands run locally:

cargo test -p socket-patch-core --lib vendor::pypi_hatch: 8 passed.
cargo clippy --workspace --all-features -- -D warnings: clean.
SOCKET_PATCH_HATCH_E2E_REQUIRED=1 SOCKET_PATCH_HATCH_E2E_VERSION=1.18.1 cargo test -p socket-patch-cli --all-features --test e2e_vex_build -- --ignored hatch::: 4 passed.
Same command with Hatch 1.0.0: 4 passed.
cargo test --workspace --all-features --no-fail-fast: 9673 passed. 65 failed, all outside this change. They were caused by the sandbox: running as root (read-only chmod fixtures can't fail a write) and the disk filling up mid-run (self-update / notifier fixtures hit ENOSPC). CI is the authority for those.
cargo fmt --all -- --check: the changed lines are fmt-clean. main itself is not rustfmt-clean repo-wide, and CI doesn't run fmt.

Follow-ups

Optional from Vendored Hatch runs a hatch executable planted in the scanned project #613: an architecture test banning Command::new("<literal>") in production code outside utils/process.rs. Not included here, to keep this change focused.

🤖 Generated with Claude Code

https://claude.ai/code/session_01BbXFWxz5BKEPH4xmF5VK7y

Note

Medium Risk
Changes subprocess invocation during PyPI Hatch vendoring in a scanned repo; behavior for legitimate Hatch on PATH should be unchanged, but spawn resolution rules are security-sensitive.

Overview
Fixes a security issue where vendored Hatch support could run a hatch binary committed inside the scanned project during the hatch --version capability probe.

The probe now follows the same pattern as other CLI spawns: resolve_tool_with picks hatch only on absolute PATH entries, and command_for runs that resolved path (with the same cwd, timeout, and version ≥1.2 gate). Missing hatch still surfaces pypi_hatch_unsupported. Logic is refactored into require_environment_context_support_with so tests can inject PATH. Unix regression tests cover planted hatch under ./empty PATH and a control case with hatch on an absolute bin dir.

^{Reviewed by Cursor Bugbot for commit e7466ea. Configure here.}

Generated by Claude Code

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions


          Start fix for #613

ea1bff4

Assisted-by: Claude Code:claude-opus-5-5

Mikola Lysenko (mikolalysenko) mentioned this pull request

Oct 2, 2026

Vendored Hatch runs a hatch executable planted in the scanned project #613

Closed

5 tasks


          Stop vendored Hatch running a planted hatch

e7466ea

Vendoring a Hatch project whose environments depend on the patched
package checks `hatch --version` from inside the project. The probe
spawned the bare name `hatch`, so with a relative PATH entry (`.` or
an empty component) it ran a `hatch` file committed to the scanned
repository: arbitrary code execution from a checkout.

The probe now looks `hatch` up on absolute PATH entries only, through
the same resolve_tool helper every other in-project spawn uses, and
runs the resolved path. When no such `hatch` exists the run takes the
existing "requires Hatch >=1.2 on PATH" refusal.

Fixes #613

Assisted-by: Claude Code:claude-opus-5-5

Mikola Lysenko (mikolalysenko) marked this pull request as ready for review

October 2, 2026 22:56

Mikola Lysenko (mikolalysenko) commented Oct 2, 2026

Copy link

Copy Markdown

Collaborator Author

BugBot review

Generated by Claude Code

cursor[bot] reacted with thumbs up emoji

All reactions

👍 1 reaction

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Mikola Lysenko (mikolalysenko) commented Oct 2, 2026

Copy link

Copy Markdown

Collaborator Author

[agent] CI note: native (ubuntu-latest, 1.1.43) in Bun patch compatibility failed. The cause is not this PR's change.

Every failing cell logs Connection reset by peer against patches-api.socket.dev, from the CLI (/patch/batch, /patch/view/…) and from the harness's own urlopen (Errno 104). The harness's 3 fresh-cell retries ran out on one cell (workspace-get-search hosted), so the result was 43/44.
This PR only changes the Hatch version probe in vendor/pypi_hatch.rs. Bun code paths never reach it.
An open fix for CLI-side resets exists in Retry patch API connections reset mid-handshake #610 (retrying transport resets in api::retry). I'm not porting it here: the cell's final attempt failed in the Python harness's urlopen, which Retry patch API connections reset mid-handshake #610 doesn't cover, so porting it wouldn't make this leg reliably green.

I'll re-run the failed job once when the workflow's last job finishes.

Generated by Claude Code

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

cursor Bot reviewed

Oct 2, 2026

View reviewed changes

cursor Bot left a comment

Copy link

Copy Markdown

There was a problem hiding this comment.

Choose a reason for 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 e7466ea. Configure here.}

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions

Mikola Lysenko (mikolalysenko) added the Ready for review Agent-verified: mergeable, CI green, Bugbot clean — awaiting human review label

Oct 3, 2026

Mikola Lysenko (mikolalysenko) commented Oct 3, 2026

Copy link

Copy Markdown

Collaborator Author

[burn-down agent] Labeled Ready for review at e7466ea61fb96be1a7caf1c60c3c6c146d506a0b.

CI: 476/476 completed check runs green (6 skipped by path filters), no failures.
Bugbot: reviewed e7466ea — no issues found; 0 unresolved review threads.
Reviewer focus: process.rs / pypi_hatch.rs: vendored Hatch now resolves hatch via absolute PATH entries instead of a bare-name spawn that could pick up an executable planted in the scanned project.
Slack announcement: not sent (Slack send tool unavailable in this run); next run will retry.

Generated by Claude Code

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Mikola Lysenko (mikolalysenko) commented Oct 3, 2026

Copy link

Copy Markdown

Collaborator Author

Reviewed e7466ea61fb96be1a7caf1c60c3c6c146d506a0b. No actionable findings; ready to merge from a code-review perspective.

The probe now uses the shared absolute-PATH resolver and spawns the resolved executable, preserving the existing version refusal, cwd, stdin and timeout behavior. 27 focused checks passed: 8 Hatch tests, 15 process-helper tests and 4 independent gate controls. Native Hatch 1.18.1 worked with relative PATH entries and planted checkout executables/Python modules; Hatch 1.0.0 retained its expected refusal.

Exact-head CI: 476 successful checks, 7 skipped, none pending or failed; all workflows completed. Bugbot is clean, no review threads remain unresolved, and the branch merges cleanly with current main (045d7ec7).

Local validation ran on macOS; Linux/Windows are covered by the completed CI runs. Human approval is still required.

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Mikola Lysenko (mikolalysenko) mentioned this pull request

Oct 3, 2026

Fix Hatch environments being invisible to stale-install checks and VEX (#335) #700

Merged

4 tasks done

Tanmay Singla (Tanmay182003) approved these changes

Oct 5, 2026

View reviewed changes

Mikola Lysenko (mikolalysenko) mentioned this pull request

Oct 5, 2026

Crawler probes spawn gem, python and npm with no timeout, so a hung shim hangs scan forever #845

Closed

4 tasks

Mikola Lysenko (mikolalysenko) merged commit 46bb258 into main

Oct 5, 2026

534 of 535 checks passed

Uh oh!

There was an error while loading. Please reload this page.

Mikola Lysenko (mikolalysenko) deleted the agent/fix-hatch-bare-spawn branch

October 5, 2026 11:18

Reviewers

cursor[bot]

cursor[bot] left review comments

Tanmay Singla (Tanmay182003)

Tanmay182003 approved these changes

Uh oh!

There was an error while loading. Please reload this page.

Assignees

No one assigned

Labels

Ready for review

Agent-verified: mergeable, CI green, Bugbot clean — awaiting human review

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Vendored Hatch runs a hatch executable planted in the scanned project

Uh oh!

There was an error while loading. Please reload this page.

3 participants

Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

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.

GeezerVison

Conversation

Mikola Lysenko (mikolalysenko) commented Oct 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

LLM Description written by Claude Code:claude-opus-5-5

Summary

Root cause

Change

Test evidence

Follow-ups

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 2, 2026

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 2, 2026

Uh oh!

cursor Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 3, 2026

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 3, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Mikola Lysenko (mikolalysenko) commented Oct 2, 2026 •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.