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

Collect publisher provenance attestations for PyPI and npm packages

Abierto
  • ¿Algo no está bien?
#907 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
65/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
python
Área
api, backend, security

Línea de trabajo

Start with the PyPI collector code to understand how distribution files are fetched. Look for the Integrity API endpoint pattern. Use sigstore-python for verification. Create tests with fixtures to avoid network calls. The first step is to fetch and store publisher provenance in extra_data, then verify the bundle.

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

Descripción

PyPI and npm both publish signed provenance for many packages now, and PurlDB doesn't collect it yet. As far as I can tell nothing in purldb, scancode-toolkit, scancode.io or vulnerablecode reads it today.

What's available:

  • PyPI (PEP 740). Per-file attestations from the Integrity API: https://pypi.org/integrity/<project>/<version>/<filename>/provenance. For sigstore 4.5.0 it returns a publisher of kind: GitHub, repository: sigstore/sigstore-python, workflow: release.yml, plus a Sigstore bundle.
  • npm. dist.attestations in the registry metadata points to SLSA v1 provenance. For [email protected] that's https://registry.npmjs.org/-/npm/v1/attestations/[email protected].

Why it'd be useful here: the attestation says which repository and workflow actually built the artifact, and a Sigstore signature backs that up. PurlDB already stores vcs_url from package metadata, but that's whatever the publisher typed. Having both lets you compare them. A package whose declared vcs_url doesn't match the repository that built it is worth a flag. That seems relevant to the malicious-package tracking planned in aboutcode-org/vulnerablecode#2438, and to filtering by vcs_url (#903).

A rough first step, which I'm happy to do:

  1. In the PyPI collector, fetch the provenance for each distribution file when it exists, and store the publisher fields (kind, repository, workflow, environment) in extra_data. No schema change.
  2. Verify the bundle with sigstore-python before storing anything, and record whether it verified. An unverified claim shouldn't look the same as a verified one.
  3. Tests with recorded fixtures, so nothing hits the network.

npm could follow the same pattern after that. If you'd rather have this in its own model or a separate pipeline instead of extra_data, tell me and I'll build it that way.

A bit about me: I've contributed to sigstore-python (#1846, merged), and I maintain a GitHub Action that attests code-review coverage with Sigstore. So verification is the part I'm most comfortable with.

Lenguaje dominante
HTML
Estrellas
70
Forks
74
Merge medio
2 d 4 h
PR fusionados (30 d)
7

Preparar el entorno

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Sin plantilla de pull request
  • Sin guía de contribución

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/purldb

Todos los issues de aboutcode-org/purldb

Issues similares

Más issues de Backend & API Design

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.