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

Aberta

#426 aberta em 1/10/2026 2 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade: 4/5
Tempo estimado: 3-5 dias
Facilidade para iniciantes: 70/100

Tipo de issue: Bug
Clareza: Claramente especificada
Status de atividade: Ativa
Stack de tecnologia: rust
Domínio: cli, tooling

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante: Rust
Estrelas: 8
Forks: 0
Merge médio: 18h 4min
PRs com merge (30d): 70

Preparar o ambiente

Sem Dockerfile nem arquivo Docker Compose
Sem modelo de pull request
Ler o guia de contribuição

Primeiros passos

Leia a issue inteira e depois o guia de contribuição do projeto.
Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
Faça um fork do repositório e trabalhe em uma branch.
Abra um pull request que referencie o número da issue.

Mais de SocketDev/socket-patch

Composer vendored repair (and re-vendor) rebuilds a deleted uuid dir without its socket-patch.vendor.json marker, leaving git showing the marker as deleted
Aberta
- Algo errado?
agent:triaged bug bughunt pm:composer priority:p2

Dificuldade 2/5 1-3 horas Facilidade para iniciantes 90/100

SocketDev/socket-patch#515 · 1 comentário · Aberta em 1/10/2026

Mantenedores costumam responder em até 1 dia
A report-only `scan -g` tells you to run `socket-patch scan --mode agent [PATHS]` without `-g`, so following the hint scans the cwd project instead of the global install
Aberta
- Algo errado?
agent:triaged bug bughunt pm:npm priority:p1

Dificuldade 2/5 1-3 horas Facilidade para iniciantes 82/100

SocketDev/socket-patch#464 · 1 comentário · Aberta em 1/10/2026

Mantenedores costumam responder em até 1 dia
remove --preserve-state on a manifest-less hosted npm project silently restores the pin without the documented hosted_state_not_preservable note
Aberta
- Algo errado?
agent:triaged bug bughunt pm:npm priority:p1

Dificuldade 2/5 1-3 horas Facilidade para iniciantes 82/100

SocketDev/socket-patch#433 · 1 comentário · Aberta em 1/10/2026

Mantenedores costumam responder em até 1 dia
Hosted rollback rewrites uv pylock.toml `upload-time` with milliseconds, so the restored file never matches what uv writes
Aberta
- Algo errado?
agent:triaged bug bughunt pm:uv priority:p1

Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100

SocketDev/socket-patch#408 · 1 comentário · Aberta em 1/10/2026

Mantenedores costumam responder em até 1 dia
Yarn berry vendored and hosted modes refuse `compressionLevel: 0 # comment` in .yarnrc.yml as a non-default compression level
Aberta
- Algo errado?
agent:triaged bug bughunt pm:yarn-berry priority:p1

Dificuldade 2/5 1-3 horas Facilidade para iniciantes 82/100

SocketDev/socket-patch#370 · 2 comentários · Aberta em 30/9/2026

Mantenedores costumam responder em até 1 dia

Todas as issues de SocketDev/socket-patch

Issues semelhantes

JMAP: opening attachments fails with attachment_data_invalid (getAttachment passes {data,size} object instead of base64)
Aberta
- Algo errado?
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 88/100

huacnlee/omamail#327 · Aberta em 3/10/2026

Mantenedores costumam responder em até 1 dia
Wrapped Chinese text can start a row with a full-width comma
Aberta
- Algo errado?
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100

emilk/egui#8659 · Aberta em 3/10/2026

Mantenedores costumam responder em até 1 dia
vmstat: -D prints "in progress IO" instead of "inprogress IO"
Aberta
- Algo errado?
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 78/100

uutils/procps#806 · Aberta em 3/10/2026

Mantenedores costumam responder em até 1 dia
bootupctl update fails to parse .bootc-aleph.json when the installed image has no version
Aberta
- Algo errado?
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 76/100

coreos/bootupd#1166 · Aberta em 3/10/2026

Mantenedores costumam responder em até 1 dia
cmp: quiet mode compares full file sizes before applying -n
Aberta
- Algo errado?
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100

uutils/diffutils#295 · Aberta em 3/10/2026

Mantenedores costumam responder em até 1 dia

Mais issues de Rust

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

Algo errado?

Avaliação

Direção de pesquisa

Descrição

Summary

Impact

Repro (Linux, dotnet SDK 8.0.131, main 2463257)

Expected vs actual

OS × SDK matrix

First bad version

Suspect code

Preparar o ambiente

Primeiros passos

Mais de SocketDev/socket-patch

Algo errado?

Algo errado?

Algo errado?

Algo errado?

Algo errado?

Issues semelhantes

Algo errado?

Algo errado?

Algo errado?

Algo errado?

Algo errado?

Receba novas issues na sua caixa de entrada

Repro (Linux, dotnet SDK 8.0.131, main `2463257`)