Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Collect publisher provenance attestations for PyPI and npm packages

Aperta
  • Qualcosa non va?
#907 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
65/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
python
Ambito
api, backend, security

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
HTML
Stelle
70
Fork
74
Merge medio
2g 4h
PR unite (30g)
7

Preparare l'ambiente

  • Include un Dockerfile o un file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di aboutcode-org/purldb

Tutte le issue di aboutcode-org/purldb

Issue simili

Altre issue su Backend & API Design

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.