Technical alignment: cross-source package metadata verification as a downstream QA layer
还没有人认领这个 Issue。
评估
调研方向
This is a design discussion, not a code task: the three questions are for maintainers to answer about purl-validator's roadmap, its scope, and whether it wants a report format or ScanCode.io hook. Start by checking the repo's roadmap and existing validation code for scope, and read the linked pkgmeta-verify schemas/pmv-output.schema.json only for context. Done means the maintainers answer the scope and interface questions, which needs their input before anyone builds.
由索引模型根据 Issue 内容生成。
描述
Technical alignment: cross-source package metadata verification as a downstream QA layer
Hi AboutCode team — I'm building a small, independent verification component that consumes existing metadata sources (registry APIs, deps.dev, ClearlyDefined, PurlDB) and produces verdicts about cross-source consistency with provenance, timestamps, and reproducible evidence. It is explicitly not another aggregator or scanner: it does not rebuild PURL databases, license scanning, or vulnerability deduplication. Think of it as a downstream QA layer that could plug into aggregation pipelines (e.g. CodeSupply's).
Before going further I wanted to check technical fit with purl-validator, since it is the closest existing piece.
What it does (PMV v0.1, Apache-2.0): https://github.com/yijigao/pkgmeta-verify
- Normalizes the same PURL across ≥2 sources per ecosystem (npm, PyPI), then adjudicates each field/version into one of:
REAL_ERROR/SYNC_DELAY/SEMANTIC_DIVERGENCE/INDETERMINATE(undecidable), each with source, timestamp, and an audit trail. - Hard rules: digest comparison only for same artifact + same algorithm; missing publication time →
undecidable, never assumed delay; empty evidence →undecidable, neverCONSISTENT. - Output schema (JSON Schema 2020-12, all instances validated):
schemas/pmv-output.schema.jsonin the repo.
Two real cases it caught (snapshots + SHA-256 manifest in evidence/):
pkg:npm/[email protected]→SEMANTIC_DIVERGENCE(license expression conjunction mismatch across sources; neither side auto-accepted).pkg:pypi/[email protected]→SYNC_DELAY(downstream lag, reported as a provable delay range only — fetch time is not treated as upstream update time).
Concrete questions:
- Does
purl-validator's roadmap include version-level existence / cross-source field-consistency checks, or is that intentionally out of scope? (I saw it currently validates base PURL existence.) - Is there an interface you'd prefer for consuming third-party verdicts like these (e.g. a specific report format, or a hook in ScanCode.io pipelines)?
- Any objection to me citing purl-validator as the "base existence layer" and this component as the "field/version consistency layer" in a funding proposal? No endorsement implied — just accurate layering.
This is a technical alignment ping only; I'm not asking for endorsement or merge commitment. Any feedback on fit or interface is welcome.
- 主要语言
- Python
- 星标
- 0
- 派生
- 2
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
aboutcode-org/purl-validator 的其他 Issue
-
难度 5/5 一周以上 新手友好度 30/100
aboutcode-org/purl-validator#31 · 1 条评论 ·
-
难度 5/5 一周以上 新手友好度 25/100
-
难度 3/5 1-2 天 新手友好度 58/100
aboutcode-org/purl-validator#29 · 2 条评论 · 2 个 reaction ·
查看 aboutcode-org/purl-validator 的全部 Issue
相似的 Issue
-
factory
难度 2/5 1-3 小时 新手友好度 78/100
Arize-ai/phoenix#17420 · 1 条评论 · 1 个 reaction ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 84/100
FireDynamics/LEDSmokeAnalysis#176 ·
维护者通常 1 天内回复
-
PC
难度 2/5 1-3 小时 新手友好度 74/100
维护者通常 1 天内回复
-
dependencies
难度 2/5 1-3 小时 新手友好度 68/100
dlt-contrib/dlt-filesystem#51 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
维护者通常 1 天内回复