Hacktoberfest 2026：維護者為十月標記出來的 issue，仍然開放、適合新手。 瀏覽 Hacktoberfest issue

Vendored Hatch runs a `hatch` executable planted in the scanned project

已關閉 適合新手
  • 哪裡不對？
#613 3 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

@mikolalysenko 已經在處理了。

開始於 2026年10月2日。

  • #617 來自 @mikolalysenko —— 未關閉

評估

難度
2/5
預估耗時
半天
新手友好度
88/100
Issue 類型
缺陷
描述清晰度
描述清楚
活躍度
活躍
技術堆疊
rust
領域
cli, security

研究方向

從 crates/socket-patch-core/src/vendor/pypi_hatch.rs 中的 require_environment_context_support 開始，並比較 utils/process.rs、vendor/npm_dir.rs 和 patch/redirect/npmrc.rs 中安全的 spawn 模式。為一個植入的 Hatch 可執行檔和一個具有絕對 PATH 的可執行檔新增回歸覆蓋，然後執行 cargo test -p socket-patch-core vendor::pypi_hatch 以及 vendored Hatch 的端對端測試；完成標準是植入的可執行檔不會被執行，且版本閘門仍然有效。

由索引模型根據 Issue 內容生成。

描述

agent:claimed agent:triaged arch-audit bug pm:hatch priority:p1

[agent] Filed by the scheduled architecture audit routine (CLI and core). Register: discussion #560 register.

Kind: bug. Source: §1 #4; Part 7.3. Register row C04.

Problem

require_environment_context_support spawns the bare name hatch from inside the scanned project:
vendor/pypi_hatch.rs#L114-L135

tokio::process::Command::new("hatch")
    .arg("--version")
    .current_dir(root)

It runs whenever a vendored Hatch project has an environment dependency on the patched package (#L103-L105).``

utils/process.rs#L23-L42 documents this exact pattern as unsafe. A relative PATH entry (. or an empty component) resolves against the child's cwd, so a bare spawn runs a hatch file committed to the repository being scanned. Every other spawn uses resolve_tool and spawns the resolved path, for example git in vendor/npm_dir.rs#L453 and node in redirect/npmrc.rs#L315. This is the only production bare-name spawn left. #442 closed the global package-manager probes but didn't touch this one.

Reproduced twice on 045d7ec with a temporary unit test in pypi_hatch.rs (not committed):

  • root/hatch is an executable script that touches root/PWNED and prints Hatch, version 1.13.0;
  • PATH is set to .:$PATH, and no real hatch is installed;
  • the test calls require_environment_context_support(root).

Output: result=Ok(()) pwned=true resolve_tool=None. The planted script ran, and its fake version also passed the >=1.2 gate. resolve_tool("hatch") returns None on the same PATH, so the shared helper would have refused it.

Symptoms

None filed. This is the same class as #421, #434 and #438 (bare spawns), which were fixed by #442 for the PM probes.

Impact

Arbitrary code execution from a scanned checkout when the user's PATH contains a relative entry, which is common in some CI images and dev shells. On macOS, posix_spawnp can run both the planted file and the real binary (see the process.rs doc). The fix is small.

Proposed change

  • Resolve with crate::utils::process::resolve_tool("hatch"). When it returns None, take the existing "Hatch >=1.2 on PATH" refusal.
  • Spawn the resolved path through process::command_for (lifted with tokio::process::Command::from), keeping current_dir(root), the null stdin, kill_on_drop and the 10 s timeout.
  • Nothing else changes; the bare spawn is deleted.

Size and scope

crates/socket-patch-core/src/vendor/pypi_hatch.rs only, about 10 production lines plus tests. Out of scope: the Hatch {root:uri} issues #505 and #547.

Acceptance criteria

  • No Command::new("hatch") remains in production code.
  • A Unix regression test: a planted executable hatch in root with PATH=.:<dirs without hatch> is not executed (its marker file is absent), and the result is pypi_hatch_unsupported.
  • A test where a real-looking hatch on an absolute PATH dir is used and passes the version gate.
  • Optional: an architecture test banning Command::new("<literal>") in core/CLI production code outside utils/process.rs, so the next bare spawn fails CI.
  • cargo test -p socket-patch-core vendor::pypi_hatch and the vendored Hatch e2e stay green.

Dependencies

None. No open PR touches pypi_hatch.rs.

主要語言
Rust
星號
8
分支
0
平均合併
1 天 1 小時
30 天內合併 PR
257

環境準備

  • 沒有 Dockerfile 或 Docker Compose 檔案
  • 沒有 Pull Request 範本
  • 閱讀貢獻指南

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

SocketDev/socket-patch 的其他 Issue

查看 SocketDev/socket-patch 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。