Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#39 1 comentario 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
18/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
python
Área
tooling

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Python
Estrellas
0
Forks
2
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de aboutcode-org/purl-validator

Todos los issues de aboutcode-org/purl-validator

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.