Trusted Publishing sollte nicht als Vertrauenssignal für Pakete verstanden werden

• Das „Vertrauen“ in Trusted Publishing bedeutet nicht, dass Menschen einem Paket vertrauen sollten, sondern bezeichnet die Beziehung zur Upload-Authentifizierung zwischen einer externen Maschinenidentität wie CI/CD und einem Paketindex
• Die PyPI-Implementierung funktioniert auf Basis einer OIDC-Föderation und reduziert die Offenlegung langlebiger, überprivilegierter Zugangsdaten, indem statt langfristiger API-Tokens kurzlebige Veröffentlichungszugangsdaten mit engem Geltungsbereich ausgegeben werden
• Nachdem PyPI die Funktion 2023 öffentlich gemacht hatte, verbreitete sie sich unter anderem zu npm, RubyGems, crates.io und NuGet; Komplexität im Datenmodell, anbieterspezifische OIDC-Behandlung und mögliche CI/CD-Kompromittierungen bleiben jedoch bestehen
• PyPI hebt den Trusted-Publishing-Status auf Projektseiten nicht mit einem grünen Häkchen hervor, sondern zeigt ihn nur als einfache Yes/No-Metadaten in den Dateidetails an, um Missverständnisse als Sicherheitssignal zu verringern
• Trusted Publishing und PyPI attestations sagen nur etwas über Upload-Authentifizierung oder Signaturen auf Basis von Maschinenidentitäten aus; ohne gesondertes Vertrauen in diese Identität lassen sich daraus keine Aussagen über Sicherheit oder Qualität eines Pakets ableiten

---

Welchen Vertrauensbereich Trusted Publishing abdeckt

• Trusted Publishing ist keine Funktion, die Menschen sagt, sie sollten einem Paket vertrauen, sondern ein Authentifizierungsverfahren für Vertrauen zwischen Maschinen
• Wenn man Trusted Publishing als Frage betrachtet, ob Menschen etwas vertrauen können oder nicht, verfehlt man die Kategorie
• Im Kern geht es darum, eine Vertrauensbeziehung für die Upload-Authentifizierung zwischen einer externen Maschinenidentität wie einem CI/CD-Workflow und der Projektidentität eines Paketindex herzustellen

Die Trusted-Publishing-Struktur von PyPI

• „Trusted Publishing“ ist der Begriff, den PyPI für ein Authentifizierungsverfahren auf Basis einer OpenID Connect-Föderation verwendet
• PyPI stellte dies 2023 öffentlich vor; danach übernahmen es auch npm, RubyGems, crates.io, NuGet und andere
• Ausgangspunkt sind zwei Probleme
  • Index-API-Tokens als langlebige Zugangsdaten sind schwer sicher zu verwalten, und Nutzer können Mindestberechtigungen und Ablaufzeiten nur schwer festlegen, weshalb sie leicht mit zu weitreichenden Rechten konfiguriert werden
  • Viele Nutzer erstellen Zugangsdaten, um sie in CI/CD-Plattformen zu hinterlegen, und CI/CD-Plattformen besitzen mit OIDC ebenfalls einen Mechanismus, um die Kontrolle über bestimmte Maschinenidentitäten nachzuweisen
• Nutzer registrieren einmalig eine CI/CD-Maschinenidentität als Trusted Publisher beim Paketindex; wenn CI/CD anschließend ein Identitätstoken vorlegt, prüft der Index dieses und stellt kurzlebige Veröffentlichungszugangsdaten mit engem Geltungsbereich aus

Vorteile und verbleibende Einschränkungen

• Der Ansatz mit kurzlebigen Zugangsdaten, deren Geltungsbereich eigenständig festgelegt wird, gilt für PyPI-Nutzer als großer Erfolg
  • Nutzer bevorzugen einen Ansatz, bei dem sie Zugangsdaten nicht selbst verwalten müssen, wenn sie nicht benötigt werden
  • Große Open-Source-Projekte und Unternehmen bevorzugen die Eigenschaft, dass Veröffentlichungsrechte nicht an einzelne Maintainer, sondern an eine Quellidentität gebunden sind
• Auch bei Trusted Publishing bleibt strukturelle Komplexität bestehen
  • Die „pending publishers“ von PyPI lösen das Problem nicht existierender Projekte, machen aber das Datenmodell komplexer und sind für Nutzer verwirrender als normales Trusted Publishing
  • OIDC-Anbieter können neben einigen gemeinsamen Claims verschiedene Werte in das Claim Set aufnehmen, sodass der Index die anbieterspezifischen Formen jeweils gesondert behandeln muss
  • Deshalb sind Maschinenidentitäten zwischen OIDC-IdPs nicht untereinander austauschbar; das ist einer der Gründe, warum PyPI neue Trusted-Publishing-Anbieter nur langsam hinzufügt
• Wird ein CI/CD-Workflow kompromittiert, kann ein Angreifer Trusted-Publishing-Zugangsdaten oder die OIDC-ID-Tokens, aus denen sie entstehen, abziehen
  • Das ähnelt dem Fall, in dem langlebige Zugangsdaten im Workflow liegen, doch Trusted-Publishing-Zugangsdaten haben nicht dasselbe Risiko hinsichtlich Geltungsbereich und Lebensdauer
  • PyPI mindert das Risiko einer CI/CD-Kompromittierung, indem es den Token-Austausch für Maschinenidentitäten verweigert, die leicht missbrauchbaren Triggern wie pull_request_target entsprechen

Warum es kein Vertrauenssignal für Pakete ist

• Trusted Publishing ist lediglich eine Authentifizierungsmethode und liefert keine Information darüber, ob ein Paket sicher, hochwertig oder empfehlenswert ist
• PyPI ist ein öffentlicher Index, in den jeder hochladen kann, und jeder kann mit einem Trusted Publisher hochladen
  • Auch mit einem Trusted Publisher lassen sich Malware oder verwundbarer Code hochladen
  • In dieser Hinsicht entspricht es anderen Upload-Authentifizierungsmethoden von PyPI, etwa API-Tokens
• Trusted Publishing ist bei PyPI nicht verpflichtend und kann es auch künftig nicht werden
  • Nutzer zu Trusted Publishing zu zwingen, ist aus Engineering-Sicht nicht realisierbar und auch technisch wie sozial nicht wünschenswert
  • Trusted Publishing bleibt immer optional

Wie die PyPI-UI Missverständnisse reduziert

• PyPI achtet darauf, dass Nutzer den Trusted-Publishing-Status nicht als Vertrauenssignal für ein Paket missverstehen
• Auf Projektseiten gibt es kein grünes Häkchen für den Trusted-Publishing-Status
• Grüne Häkchen für nutzergesteuerte Zustände werden nur für Links verwendet, bei denen PyPI nachweisen kann, dass sie aus derselben Quelle stammen wie das Paket selbst
• Eine verifizierte URL beweist nur, dass diese URL zum Zeitpunkt der Verifizierung unter Kontrolle des Besitzers des PyPI-Pakets stand; sie bedeutet keine zusätzliche Sicherheit der URL oder des Projekts
• Der Trusted-Publishing-Status einer bestimmten Datei wird in den Dateidetails als einfacher Yes/No-Wert angezeigt
  • Der Bereich für Dateimetadaten wird nicht so gerendert, als handele es sich um wichtige Informationen für die Vertrauensentscheidung des Nutzers
  • Auch ein JSON-Blob aus dem User Agent des Upload-Clients wird nicht ordentlich gerendert

Abgrenzung zu attestations

• Dieser Punkt ist von den attestations von PyPI getrennt
• Auch attestations verwenden derzeit OIDC-Maschinenidentitäten, sind aber kein Vertrauenssignal
• Eine attestation ähnelt einer Signatur auf einer Maschinenidentität, aber da bei PyPI jeder hochladen kann, kann auch jeder mit einer von ihm kontrollierten Maschinenidentität signieren
• Dass ein Trusted Publisher existiert, bedeutet nicht zwangsläufig, dass eine attestation vorhanden ist; und eine vorhandene attestation bedeutet nicht, dass Endnutzer einer bestimmten Identität vertrauen sollten
• Auch das Vertrauenswürdigkeitsmodell der PyPI-attestations dokumentiert diesen Punkt

[GN⁺]

Kommentare auf Lobste.rs

• Guter Beitrag. Trusted Publishing und Attestation bieten jeweils unterschiedliche Garantien für unterschiedliche Fehlermodi, und beides ist etwas anderes als das, was die meisten Nutzer unter Vertrauen verstehen.

• Trusted Publishing ist möglich geworden, weil in den letzten 15 Jahren viele Open-Source-Projekte vom Self-Hosting – etwa Mailinglisten, Git-Repositories, Bugtracker und Build-Server – zu zentralisierten Forges gewechselt sind.
  Jetzt, da die Nachteile zentralisierter Forges deutlicher werden, ziehen Projekte wieder Self-Hosting in Betracht.
  In den 2010er-Jahren haben Bequemlichkeit und soziale Netzwerkeffekte Projekte in zentralisierte Forges gedrängt; inzwischen gibt es aber viel mehr Faktoren, die Projekte dort binden, darunter Trusted Publishing.
  Misstraue Autorität — fördere Dezentralisierung
  — „The Hacker Ethics“, Hackers: Heroes of the Computer Revolution (Steven Levy, 1984)

  • Bei Trusted Publishing gibt es keinen Lock-in. Man kann jederzeit eine andere Authentifizierungsmethode verwenden, einschließlich Hosts, mit denen PyPI integrieren kann.
    Es hat eine gewisse Ironie, föderierte Authentifizierung als eine Form von Lock-in zu bezeichnen.
  • Self-Hosting war praktisch immer eher etwas für eine Minderheit. Genau darin lag der Zweck von SourceForge: diese Last abzunehmen.
    Etwa zur gleichen Zeit, vor rund 25 Jahren, gab es auch die ASF, aber die brachte ebenfalls erheblichen Governance-Aufwand mit sich. Davor gab es das GNU-Projekt, das stärker die Ideologie freier Software betonte und sich weniger auf einen systematischen Projekt-Hosting-Dienst konzentrierte. GNU existierte schon, bevor es eine klare Vorstellung davon gab, welche Dienste freie Softwareprojekte benötigen.
    Freie-Software-Projekte der 1990er-Jahre lagen typischerweise auf Timesharing-Diensten von Universitäten oder auf Colocation-Servern von Freunden. Beispiele sind PuTTY oder Hyperreal.org, wo Apache httpd vor der ASF-Zeit lag.
    Nur wenige Projekte wurden groß genug, um eigene Infrastruktur zu rechtfertigen, und günstiges Hosting ist auch erst vergleichsweise seit Kurzem verfügbar.
  • Gibt es einen Grund, warum Trusted Publishing mit einem selbst gehosteten Forgejo nicht funktionieren sollte? Falls ja, übersehe ich ihn wohl.