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

• Das „Vertrauen“ bei 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 dem Paketindex
• Die Implementierung von PyPI basiert auf einer OIDC-Föderation und stellt kurzlebige, eng begrenzte Veröffentlichungs-Anmeldedaten statt langlebiger API-Tokens aus, um die Offenlegung langlebiger und überprivilegierter Anmeldedaten zu verringern
• Nach der Einführung durch PyPI im Jahr 2023 hat sich das Verfahren auf npm, RubyGems, crates.io, NuGet und weitere ausgebreitet, doch die Komplexität des Datenmodells, die provider-spezifische OIDC-Verarbeitung und die Möglichkeit kompromittierter CI/CD-Systeme bleiben bestehen
• PyPI hebt den Trusted-Publishing-Status nicht mit einem grünen Häkchen auf der Projektseite hervor, sondern zeigt ihn nur als einfache Yes/No-Metadaten in den Dateidetails an, um Missverständnisse als Sicherheitssignal zu vermeiden
• Trusted Publishing und PyPI-Attestations sagen nur etwas über Upload-Authentifizierung oder Signaturen auf Basis von Maschinenidentitäten aus; bevor man dieser Identität separat vertraut, lässt sich daraus nichts über Sicherheit oder Qualität eines Pakets ableiten

---

Worum es beim Vertrauen in Trusted Publishing geht

• Trusted Publishing ist keine Funktion, die Menschen dazu auffordert, einem Paket zu vertrauen, sondern ein Authentifizierungsverfahren für Vertrauen zwischen Maschinen
• Trusted Publishing als Frage zu betrachten, ob Menschen dem Paket vertrauen können oder nicht, verfehlt 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 im Paketindex herzustellen

Aufbau von Trusted Publishing in PyPI

• „Trusted Publishing“ ist der Begriff, den PyPI für ein Authentifizierungsverfahren auf Basis einer OpenID Connect-Föderation verwendet
• PyPI hat dies 2023 eingeführt; danach haben es auch npm, RubyGems, crates.io, NuGet und andere übernommen
• Ausgangspunkt sind zwei Probleme
  • Langlebige Anmeldedaten wie API-Tokens für den Index lassen sich nur schwer sicher verwalten, und für Nutzer ist es schwer, Prinzip der minimalen Rechte und Ablaufzeiten sauber festzulegen, sodass sie leicht überprivilegiert werden
  • Viele Nutzer erstellen Anmeldedaten, um sie in CI/CD-Plattformen zu hinterlegen, und diese Plattformen verfügen über Mechanismen, mit OIDC die Kontrolle über bestimmte Maschinenidentitäten nachzuweisen
• Nutzer registrieren einmal eine CI/CD-Maschinenidentität als Trusted Publisher im Paketindex; präsentiert CI/CD dann ein Identitätstoken, prüft der Index dieses und stellt kurzlebige, eng begrenzte Veröffentlichungs-Anmeldedaten aus

Vorteile und verbleibende Einschränkungen

• Das Modell kurzlebiger Anmeldedaten mit inhärent begrenztem Scope gilt für PyPI-Nutzer als sehr erfolgreicher Ansatz
  • Nutzer bevorzugen einen Ansatz, bei dem sie Anmeldedaten nicht selbst verwalten müssen, wenn das nicht nötig ist
  • Große Open-Source-Projekte und Unternehmen bevorzugen, dass Veröffentlichungsrechte an eine Quellidentität statt an einzelne Maintainer 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-Provider können über einige gemeinsame Claims hinaus sehr unterschiedliche Werte in ihren Claim-Sets ausliefern, sodass der Index die Eigenheiten jedes Providers separat behandeln muss
  • Deshalb sind Maschinenidentitäten zwischen OIDC-IdPs nicht austauschbar, was einer der Gründe ist, warum PyPI neue Trusted-Publishing-Provider nur langsam ergänzt
• Wird ein CI/CD-Workflow kompromittiert, kann ein Angreifer Trusted-Publishing-Anmeldedaten oder das zugrunde liegende OIDC-ID-Token abgreifen
  • Das ähnelt der Situation, wenn langlebige Anmeldedaten im Workflow vorhanden sind, doch Trusted-Publishing-Anmeldedaten tragen nicht dieselben Risiken bei Scope und Lebensdauer
  • PyPI mindert das Risiko kompromittierter CI/CD-Systeme, indem es den Token-Austausch für Maschinenidentitäten verweigert, die zu leicht missbrauchbaren Triggern wie pull_request_target gehören

Warum es kein Vertrauenssignal für Pakete ist

• Trusted Publishing ist nur eine Authentifizierungsmethode und sagt nichts darüber aus, ob ein Paket sicher ist, hohe Qualität hat oder sinnvoll nutzbar ist
• PyPI ist ein öffentlicher Index; jeder kann hochladen, und jeder kann dafür auch einen Trusted Publisher verwenden
  • Auch mit einem Trusted Publisher lassen sich Malware oder verwundbarer Code hochladen
  • In diesem Punkt unterscheidet es sich nicht von API-Tokens als anderer Upload-Authentifizierungsmethode in PyPI
• Trusted Publishing ist in PyPI nicht verpflichtend und kann es auch künftig nicht werden
  • Nutzer zu Trusted Publishing zu zwingen, ist technisch nicht praktikabel und auch technisch wie sozial nicht wünschenswert
  • Trusted Publishing bleibt immer optional

Wie die PyPI-Oberfläche Missverständnisse reduziert

• PyPI geht vorsichtig damit um, dass Nutzer den Trusted-Publishing-Status nicht als Vertrauenssignal für Pakete missverstehen
• Auf Projektseiten gibt es kein grünes Häkchen, das den Trusted-Publishing-Status zeigt
• Grüne Häkchen für vom Nutzer kontrollierte Zustände werden nur für Links verwendet, bei denen PyPI nachweisen kann, dass sie aus derselben Quelle wie das Paket selbst stammen
• Verifizierte URLs belegen nur, dass die jeweilige URL zum Zeitpunkt der Verifizierung unter der Kontrolle des PyPI-Paketbesitzers stand; sie bedeuten keine zusätzliche Sicherheit für URL oder Projekt
• Der Trusted-Publishing-Status einer bestimmten Datei wird in den Dateidetails nur als einfacher Yes/No-Wert angezeigt
  • Der Bereich mit Dateimetadaten ist nicht so gestaltet, als wäre er eine besonders wichtige Grundlage für Vertrauensentscheidungen der Nutzer
  • Auch JSON-Blobs aus dem User Agent des Upload-Clients werden nicht prominent aufbereitet dargestellt

Abgrenzung zu Attestations

• Dieser Punkt ist getrennt von den Attestations von PyPI zu betrachten
• Auch Attestations nutzen derzeit OIDC-Maschinenidentitäten, sind aber kein Vertrauenssignal
• Eine Attestation ähnelt einer Signatur auf Basis einer Maschinenidentität, doch da jeder auf PyPI hochladen kann, kann auch jeder mit einer von ihm kontrollierten Maschinenidentität signieren
• Aus einem Trusted Publisher folgt nicht, dass zwingend eine Attestation existiert, und aus einer Attestation folgt nicht, dass Endnutzer einer bestimmten Identität vertrauen sollten
• Auch das Vertrauensmodell für Attestations in PyPI dokumentiert diesen Punkt in der Dokumentation

[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.