VEX product purl detected from pyproject.toml keeps the raw project name (pkg:pypi/My_Service) instead of the normalized pypi name
メンテナーはふだん 1 日以内に返信
関連するプルリクエストがすでにマージされています。
- #1577 @mikolalysenko による — マージ済み
評価
- 難易度
- 2/5
- 見積もり時間
- 1〜3時間
- 初心者へのやさしさ
- 80/100
調査の方向性
バグは crates/socket-patch-core/src/vex/product.rs の parse_pyproject にあります（157〜167行目付近）。ここでは生のプロジェクト名から pypi の purl を組み立てています。同じファイル内の、すでに名前を小文字に変換している npm と composer の分岐と比較し、issue で言及されている PEP 503 のヘルパーを確認してください。My_Service から pkg:pypi/[email protected]、Demo_Pkg.Core から pkg:pypi/[email protected] が得られれば完了です。両方のケースを対象とするユニットテストを追加してください。
索引モデルが issue の本文から書いたものです。
説明
[agent] Found by the scheduled Poetry bug-hunt routine (ledger #311).
Summary
When vex (or scan --vex / apply --vex) auto-detects the top-level product from pyproject.toml, it copies the project name verbatim into the purl. A Poetry project named My_Service gets the product pkg:pypi/[email protected], and Demo_Pkg.Core gets pkg:pypi/[email protected]. The purl spec's pypi type says the name must be lowercased with _ replaced by - (PyPI compares names in PEP 503 form, which also maps . to -). So the expected products are pkg:pypi/[email protected] and pkg:pypi/[email protected] (demo-pkg-core in full PEP 503 form).
The npm and composer branches of the same detector already lowercase their names (product.rs, e.g. parse_composer_json), and the rest of the codebase compares PyPI names in PEP 503 form (crawlers/fuzzy_match.rs, crawlers/hatch_env.rs). Only the pyproject branch skips it.
Impact
An OpenVEX consumer matches products[].@id against the product identifier in the SBOM or scan it is applied to. SBOM generators emit the normalized pypi purl, so a VEX document saying pkg:pypi/My_Service@… won't match the project by exact purl, and its not_affected statements are silently ignored. That affects every Python project whose name has uppercase letters or _, which is common: Poetry, PDM and hatch all accept and preserve such names. It isn't Poetry-specific; any pyproject-based product goes through parse_pyproject. --vex-product / --product work around it.
Repro (Linux, main fc1b4f9)
Uses a local mock of the patch API serving one patched six-1.16.0 wheel. The same result comes from any pypi patch.
# Poetry 2.5.1, PEP 621 layout, agent mode + standalone vex
mkdir proj && cd proj
printf '[project]\nname = "My_Service"\nversion = "1.2.0"\nrequires-python = ">=3.9"\ndependencies = ["six==1.16.0"]\n\n[tool.poetry]\npackage-mode = false\n' > pyproject.toml
POETRY_VIRTUALENVS_IN_PROJECT=true poetry lock && poetry install
socket-patch scan --mode agent --json --yes --api-url $MOCK --api-token x --org test-org
socket-patch vex -O v.json --json --api-url $MOCK --api-token x --org test-org
jq -r '.statements[].products[]."@id"' v.json
# → pkg:pypi/[email protected] (expected pkg:pypi/[email protected])
# Poetry 1.8.5, legacy [tool.poetry] layout, hosted + same-run VEX
# [tool.poetry] name = "My_Service", version = "0.1.0", six = "1.16.0"
socket-patch scan --mode hosted --vex out.vex.json --json --yes …
# → pkg:pypi/[email protected]
# Poetry 2.5.1, [tool.poetry] name = "Demo_Pkg.Core"
# → pkg:pypi/[email protected]
For reference, packaging.utils.canonicalize_name("My_Service") is my-service.
Expected vs actual
- Expected: CLI_CONTRACT.md /
product.rs's module doc saypyproject.tomlmaps topkg:pypi/<name>@<version>, and a pypi purl's name is the normalized one (purl spec, pypi type: lowercase,_→-), as the component purls in the same document already are (pkg:pypi/[email protected]). - Actual: the name is emitted byte for byte as written in
[project].name/[tool.poetry].name.
OS × version
| OS | Poetry | Layout | Path | Result |
|---|---|---|---|---|
| Linux | 1.8.5 | [tool.poetry] |
scan --mode hosted --vex |
reproduces |
| Linux | 2.5.1 | [project] |
agent scan + vex |
reproduces |
| Linux | 2.5.1 | [tool.poetry] |
scan --mode hosted --vex |
reproduces |
| macOS / Windows | any | any | — | not run (the code path is OS-independent string handling) |
Suspect code
crates/socket-patch-core/src/vex/product.rs:157-167 (parse_pyproject builds format!("pkg:pypi/{name}@{version}") from pyproject_name_version without normalizing). The PEP 503 helper consolidated under #883 could be reused here.
- 主要言語
- Rust
- スター
- 8
- フォーク
- 1
- 平均マージ
- 16時間 18分
- マージ済み PR（30日）
- 587
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
SocketDev/socket-patch のほかの issue
-
agent:triaged bug bughunt pm:pipenv priority:p1
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
SocketDev/socket-patch#1608 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
agent:triaged bug bughunt pm:vlt priority:p1
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
SocketDev/socket-patch#1601 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
agent:triaged bug bughunt pm:npm priority:p3 ux
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
SocketDev/socket-patch#1072 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信
-
agent:triaged bug bughunt pm:yarn-berry priority:p1
難易度 2/5 1〜3時間 初心者へのやさしさ 73/100
SocketDev/socket-patch#783 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
Vendored cargo warns cargo_multi_version_old_cargo ("declares no rust-version") when the root package inherits rust-version from [workspace.package]対応中かも @mikolalysenko が 4 日前に担当しました。 オープンagent:triaged bug bughunt pm:cargo priority:p2
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
SocketDev/socket-patch#651 · コメント 3 件 ·
メンテナーはふだん 1 日以内に返信
SocketDev/socket-patch の issue をすべて見る
似ている issue
-
area: compat area: parsing bug
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
reubeno/brush#1526 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
OFN writer emits `DocIRI` as a bare IRI, which becomes a version IRI or a parse error on re-readオープン
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
phillord/horned-owl#338 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
type/bug
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
stackabletech/operator-rs#1301 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
jmcnamara/rust_xlsxwriter#205 · コメント 4 件 ·