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

Composer crawler ignores a vendor-dir set in the global Composer config, so scan -g and agent scans report "No packages found" and leave installs unpatched

未關閉
  • 哪裡不對？
#439 1 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

還沒有人認領這個 Issue。

評估

難度
4/5
預估耗時
3-5 天
新手友好度
72/100
Issue 類型
缺陷
描述清晰度
描述清楚
活躍度
活躍
技術堆疊
php, rust
領域
cli, tooling

研究方向

Start in crates/socket-patch-core/src/crawlers/composer_crawler.rs, reading get_vendor_paths at lines 52-64 and resolve_local_vendor_dir at lines 473-492. Reproduce the global and local cases from the issue with Composer and the listed socket-patch scan commands, then verify scans discover packages installed through global, project, and COMPOSER_HOME configuration. Done means configured vendor directories are found and no longer produce empty successful scans.

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

描述

agent:triaged bug bughunt pm:composer priority:p2

[agent] Found by the scheduled Composer bug-hunt routine (ledger #321).

Summary

Composer resolves vendor-dir through its config cascade: COMPOSER_VENDOR_DIR, then the project's composer.json config.vendor-dir, then the user-level $COMPOSER_HOME/config.json. The socket-patch Composer crawler follows only part of that cascade, so real installs go undiscovered:

  1. Global (-g): get_vendor_paths hardcodes $COMPOSER_HOME/vendor (crates/socket-patch-core/src/crawlers/composer_crawler.rs:52-64). If the global project sets config.vendor-dir (composer global config vendor-dir deps, or "config":{"vendor-dir":"deps"} in $COMPOSER_HOME/composer.json), or COMPOSER_VENDOR_DIR is exported, composer global require installs to $COMPOSER_HOME/deps. scan -g then finds 0 packages, and scan -g --mode agent prints No global packages found. with exit 0.
  2. Local (agent mode): resolve_local_vendor_dir (composer_crawler.rs:473-492) reads COMPOSER_VENDOR_DIR and the project composer.json, but not the user-level $COMPOSER_HOME/config.json. After composer config -g vendor-dir lib, every project's composer install writes to lib/, and socket-patch scan --mode agent reports No composer packages found. (exit 0) while the package stays unpatched.

In both cases the failure is silent, with exit 0 and nothing patched or attested.

Repro (Linux; Composer 2.8.12, mock patch API, local path-repo package acme/[email protected])

# 1. global
export COMPOSER_HOME=$PWD/ch
composer global config repositories.local '{"type":"path","url":"/abs/pkgs/tool","options":{"symlink":false}}'
composer global config vendor-dir deps
composer global require acme/tool:1.0.0          # -> $COMPOSER_HOME/deps/acme/tool
socket-patch scan -g --json --ecosystems composer        # packagesWithPatches 0, scannedPackages 0
socket-patch scan -g --mode agent --yes --ecosystems composer   # "No global packages found." exit 0
socket-patch scan --global-prefix "$COMPOSER_HOME/deps" --json --ecosystems composer   # finds 1 (workaround)

# 2. local, user-level config
composer config -g vendor-dir lib                 # writes $COMPOSER_HOME/config.json
composer install                                  # -> ./lib/acme/tool
socket-patch scan --mode agent --yes --ecosystems composer      # "No composer packages found."

COMPOSER_VENDOR_DIR=gdeps composer global require … followed by COMPOSER_VENDOR_DIR=gdeps socket-patch scan -g also finds nothing. Composer resolves the variable against the global home, while the global branch never reads it.

Expected vs actual

  • Expected: CLI_CONTRACT.md --global: "Operate on globally-installed packages". The crawler's local-mode doc promises COMPOSER_VENDOR_DIR / config.vendor-dir support, and Composer applies the same cascade (including config.json) to the global project and to every local one. The maintainer requirement for -g is that none may be missing.
  • Actual: packages installed under a configured vendor-dir are invisible, and the commands exit 0.

OS × version

OS Composer global vendor-dir → scan -g / apply -g user config.json vendor-dir → local agent scan
Linux (local) 1.10.28, 2.2.30, 2.8.12, 2.10.3 (PHP 8.3) fail (each run twice) fail (2.8.12, twice)
ubuntu-latest 1.10.28, 2.2.30, 2.10.3 fail untested
macos-latest 1.10.28, 2.2.30, 2.10.3 fail untested
windows-latest 1.10.28, 2.2.30, 2.10.3 fail untested

The default vendor/ layout passes everywhere except Windows, where default-home discovery is broken separately (#438).

Probe runs: https://github.com/SocketDev/socket-patch/actions/runs/36823671080 and https://github.com/SocketDev/socket-patch/actions/runs/36827949605

First bad version

Not a regression. It reproduces identically with the v4.0.0 release binary (both cases: 0 scanned).

Suspect code

  • crates/socket-patch-core/src/crawlers/composer_crawler.rs:52-64 (global: composer_home.join("vendor"))
  • crates/socket-patch-core/src/crawlers/composer_crawler.rs:473-492 (local: no $COMPOSER_HOME/config.json layer)
主要語言
Rust
星號
8
分支
0
平均合併
1 天 31 分鐘
30 天內合併 PR
151

環境準備

  • 沒有 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 摘要。