theupdateframework / theupdateframework/python-tuf

Request: independently verifiable source signing and reproducible-build details for v7.0.0

Offen
#2,979 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Vorherrschende Sprache
Python
Sterne
1.7k
Forks
304
Ø Merge
1 T. 2 Std.
Gemergte PRs (30 T.)
17

Beschreibung

Hello maintainers,

I am reviewing python-tuf v7.0.0 for use in a security-sensitive, offline-verification workflow.

I could verify the following GitHub objects:

  • Annotated tag object: fed65f73486314242cc738fc7c5c891f5d7fc369
  • Peeled commit: 353bdb767db56fd4667c9bcf56b710d50fdc2ac0

GitHub shows the tag as verified through GitHub's web-flow signing key. However, I have not found an independently published maintainer signature or key binding that can authenticate these source objects without initially trusting GitHub as the identity authority.

Could you please clarify:

  1. Is there an official non-GitHub location that binds the v7.0.0 tag or commit to a maintainer-controlled signing-key fingerprint?
  2. Is a detached signature or signed release statement available for the tag, commit, or source archive?
  3. What is the canonical SHA-256 digest of the source archive used to build the published v7.0.0 artifacts?
  4. What exact build-tool and dependency versions were used for the release?
  5. Are the wheel and source distribution intended to be byte-for-byte reproducible from the tagged source? If not, which content-level comparison is considered authoritative?
  6. Are there plans to publish provenance or attestations that bind the source commit to the PyPI artifacts?

This is a supply-chain provenance question, not a vulnerability report. No private repository information or credentials are involved.

Thank you.

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

  1. Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
  3. Forke das Repository und arbeite in einem Branch.
  4. Öffne einen Pull Request, der die Issue-Nummer nennt.

Rechercherichtung

Beginne mit der Überprüfung des annotierten Tags v7.0.0, des peeled commit, des source archive, der wheel und der in der Issue genannten source distribution. Überprüfe den Release- und Packaging-Prozess des Projekts auf Maintainer-Signaturen, Schlüsselbindungen, Hashes, Versionen der Build-Tools und Abhängigkeiten sowie Provenance-Datensätze. Als erledigt gilt die Aufgabe, wenn maßgebliche Antworten auf die sechs angeforderten Fragen zu Provenance und Reproduzierbarkeit dokumentiert oder veröffentlicht sind.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Bewertung

Tech-Stack
git, github, python
Bereich
build-system, documentation, release, security
Issue-Typ
Dokumentation
Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Aktivitätsstatus
Ruhig
Klarheit
Größtenteils klar
Anfängerfreundlichkeit
42/100

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.