Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Global scan (-g) never crawls .NET global tools (~/.dotnet/tools/.store), so a patched `dotnet tool install -g` package is silently left out of scan, apply and vex on every OS

未关闭
  • 哪里不对？
#426 2 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
70/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
rust
领域
cli, tooling

调研方向

Start with crates/socket-patch-core/src/crawlers/nuget_crawler.rs, especially the global branch, get_nuget_package_paths, and nuget_home. Reproduce the Linux case with a global dotnet tool, then inspect how scan, apply, and vex consume crawler results. Done means global scans discover the .NET tool store across the documented OS and prefix cases, with coverage for the resulting package paths.

由索引模型根据 Issue 内容生成。

描述

agent:triaged bug bughunt pm:nuget priority:p3

[agent] Found by the scheduled NuGet / dotnet bug-hunt routine (ledger #320).

Summary

dotnet tool install -g <id> is the .NET way to install a package globally. The SDK restores the tool package into its own packages folder, ~/.dotnet/tools/.store/<id>/<ver>/ (%USERPROFILE%\.dotnet\tools\.store\... on Windows), as <id>/<ver>/<id>.nuspec + tools/<tfm>/any/*.dll. It does not go into ~/.nuget/packages.

socket-patch scan -g only crawls NUGET_PACKAGES / ~/.nuget/packages. So a globally installed .NET tool is never sent to the patch API, never listed, and can't be patched or attested:

  • scan -g (report-only): the tool's purl is missing from the batch request and the table. Exit 0, no warning.
  • apply -g with a manifest entry for the tool: 0 of 1 targeted patch applied, ... 1 not found on disk, exit 1. At least this one is loud.
  • vex -g: omitting pkg:nuget/[email protected] from VEX: the package is not installed (package_not_found).
  • --global-prefix ~/.dotnet/tools/.store doesn't help either: 0 packages, because each tool is its own nested packages folder (.store/<id>/<ver>/<id>/<ver>/). Only --global-prefix ~/.dotnet/tools/.store/<id>/<ver> (one tool at a time) finds it, and then apply and rollback work.

This is the .NET sibling of #415 (pipx venvs never crawled by scan -g).

Impact

On any machine or CI image with .NET global tools (dotnet-ef, dotnet-format, dotnet-outdated-tool, GitVersion.Tool, Cake.Tool, …), scan -g reports a clean result and never surfaces their patches. The user gets no signal that this location wasn't checked.

Repro (Linux, dotnet SDK 8.0.131, main 2463257)

SP=/path/to/target/release/socket-patch
export SOCKET_NO_CONFIG=1 SOCKET_TELEMETRY_DISABLED=1
dotnet tool install -g dotnetsay --version 3.0.3
ls ~/.dotnet/tools/.store/dotnetsay/3.0.3/dotnetsay/3.0.3/dotnetsay.nuspec   # present
ls ~/.nuget/packages/dotnetsay 2>&1                                           # absent
# run a local stand-in for the public proxy that answers POST /patch/batch with a patch
# for every pkg:nuget purl it receives and logs the request body, then:
$SP scan -g -e nuget --json --proxy-url http://127.0.0.1:8765
# -> the batch body has only the ~/.nuget/packages purls; pkg:nuget/[email protected] is never sent
$SP scan --global-prefix ~/.dotnet/tools/.store -e nuget --json --proxy-url ...            # scannedPackages: 0
$SP scan --global-prefix ~/.dotnet/tools/.store/dotnetsay/3.0.3 -e nuget --json --proxy-url ...  # finds [email protected]
# with a hand-staged .socket/manifest.json entry for pkg:nuget/[email protected] (README.md):
$SP apply -g --offline    # "1 not found on disk", exit 1
$SP vex -g --offline --product pkg:nuget/[email protected]   # package_not_found, exit 1

Expected vs actual

  • Expected: scan -g covers every location where NuGet / dotnet installs packages globally. CLI_CONTRACT.md documents --global as "Operate on globally-installed packages", and the report-only --global scan as discovery of the machine tree. For .NET that includes the global tool store. If it's deliberately out of scope, the docs should say so, and scan -g should say it skipped the tool store.
  • Actual: only ~/.nuget/packages is crawled (get_nuget_package_paths, crates/socket-patch-core/src/crawlers/nuget_crawler.rs:41-50, nuget_home() at :392). Nothing in README.md, docs/ecosystems.md or CLI_CONTRACT.md mentions .dotnet/tools.

OS × SDK matrix

Probe run: https://github.com/SocketDev/socket-patch/actions/runs/36820498426 (8/8 jobs; real dotnet tool install -g, real dotnet restore).

OS SDK tool scan -g lists the tool apply -g patches the tool
Linux (local) 8.0.131 dotnetsay 3.0.3 no no (rc 1, not found)
ubuntu-latest 6.0.x dotnetsay 2.1.7 no no (rc 1)
ubuntu-latest 9.0.x dotnetsay 3.0.3 no no (rc 1)
ubuntu-latest 10.0.x dotnetsay 3.0.3 no no (rc 1)
macos-latest 8.0.x dotnetsay 3.0.3 no no (rc 1)
macos-latest 9.0.x dotnetsay 3.0.3 no no (rc 1)
windows-latest 8.0.x dotnetsay 3.0.3 no no (rc 1)
windows-latest 9.0.x dotnetsay 3.0.3 no no (rc 1)
windows-latest 10.0.x dotnetsay 3.0.3 no no (rc 1)

First bad version

Not a regression: v4.0.0 (GitHub release binary) sends the same batch with no tool purl.

Suspect code

crates/socket-patch-core/src/crawlers/nuget_crawler.rs:41-50: the global branch returns [nuget_home()] only. A fix would also enumerate ~/.dotnet/tools/.store/*/*/ (and DOTNET_CLI_HOME if set) as additional packages folders. dotnet tool install --tool-path <dir> installs use <dir>/.store/... with the same layout.

主要语言
Rust
星标
8
派生
0
平均合并
1 天 7 分钟
30 天内合并 PR
178

环境准备

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