Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Technical alignment: cross-source package metadata verification as a downstream QA layer

Ouverte
  • Quelque chose ne va pas ?
#39 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
18/100
Type d'issue
Fonctionnalité
Clarté
À clarifier
Activité
Active
Stack technique
python
Domaine
tooling

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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, never CONSISTENT.
  • Output schema (JSON Schema 2020-12, all instances validated): schemas/pmv-output.schema.json in the repo.

Two real cases it caught (snapshots + SHA-256 manifest in evidence/):

  1. pkg:npm/[email protected] → SEMANTIC_DIVERGENCE (license expression conjunction mismatch across sources; neither side auto-accepted).
  2. 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:

  1. 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.)
  2. 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)?
  3. 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.

Langage dominant
Python
Étoiles
0
Forks
2
Aucune PR mergée en 30 j

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de aboutcode-org/purl-validator

Toutes les issues de aboutcode-org/purl-validator

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.