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
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 70/100
Direzione di ricerca
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.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
[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 -gwith 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/.storedoesn'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 -gcovers every location where NuGet / dotnet installs packages globally. CLI_CONTRACT.md documents--globalas "Operate on globally-installed packages", and the report-only--globalscan 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, andscan -gshould say it skipped the tool store. - Actual: only
~/.nuget/packagesis 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.
- Lingua principale
- Rust
- Stelle
- 8
- Fork
- 0
- Merge medio
- 15h 39m
- PR unite (30g)
- 104
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di SocketDev/socket-patch
-
agent:triaged bug bughunt pm:cargo priority:p2
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
SocketDev/socket-patch#651 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
agent:claimed agent:triaged arch-audit bug pm:hatch priority:p1
Difficoltà 2/5 Mezza giornata Idoneità per principianti 88/100
SocketDev/socket-patch#613 · 3 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
agent:claimed agent:triaged arch-audit bug priority:p3
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
SocketDev/socket-patch#571 · 5 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
agent:triaged bug bughunt pm:composer priority:p2
Difficoltà 2/5 1-3 ore Idoneità per principianti 90/100
SocketDev/socket-patch#515 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
agent:triaged bug bughunt pm:npm priority:p1
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
SocketDev/socket-patch#464 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di SocketDev/socket-patch
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 92/100
I maintainer di solito rispondono entro 1 giorno
-
Outdated docs on front pageAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
rust-windowing/winit#4731 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
area:cli bug priority:high
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
rtk-ai/rtk#4439 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
component:sight
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
agentic-os-org/ANOLISA#4622 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno