GitHub hat einen Vorschlag zur Diskussion gestellt, um den Sigstore-Dienst zur Verifizierung von Paketen mittels digitaler Signaturen und zur Führung eines öffentlichen Logs zur Bestätigung der Authentizität bei der Verbreitung von Releases einzuführen. Der Einsatz von Sigstore ermöglicht es, eine zusätzliche Schutzebene gegen Angriffe zu implementieren, die auf die Manipulation von Softwarekomponenten und Abhängigkeiten (Supply Chain) abzielen. So wird beispielsweise die eingeführte Änderung den Quellcode von Projekten schützen, falls das Konto eines Entwicklers einer der Abhängigkeiten in NPM kompromittiert wird und ein Angreifer ein Paketupdate mit schädlichem Code erstellt.
Dank des neuen Schutzlevels können Entwickler das erstellte Paket mit dem verwendeten Quellcode und der Build-Umgebung verknüpfen, sodass der Benutzer sicherstellen kann, dass der Inhalt des Pakets mit dem der Quelltexte im Hauptrepository des Projekts übereinstimmt. Der Einsatz von Sigstore vereinfacht den Schlüsselmanagementprozess erheblich und beseitigt die Schwierigkeiten, die mit der Registrierung, dem Widerruf und dem Management kryptografischer Schlüssel verbunden sind. Sigstore wird als Pendant zu Let’s Encrypt für Code präsentiert, das Zertifikate zur Beglaubigung von Code durch digitale Signaturen und Tools zur Automatisierung der Überprüfung bereitstellt.
Statt permanenter Schlüssel verwendet Sigstore kurzlebige, ephemeral Schlüssel, die basierend auf den Berechtigungen generiert werden. Das Material, das zur Signierung verwendet wird, wird in einem manipulationssicheren öffentlichen Log festgehalten, das sicherstellt, dass der Unterzeichner tatsächlich der ist, für den er sich ausgibt, und dass die Unterschrift vom selben Teilnehmer erstellt wurde, der für frühere Releases verantwortlich war. Um die Integrität zu gewährleisten und eine nachträgliche Datenmanipulation zu verhindern, wird eine baumartige Struktur, das sogenannte "Merkle-Baum" (Merkle Tree), eingesetzt, bei dem jeder Ast alle darunter liegenden Äste und Knoten durch gemeinsames (baumartiges) Hashing verifiziert. Mit einem endgültigen Hash kann der Benutzer die Richtigkeit der gesamten Betriebshistorie sowie die Korrektheit früherer Datenbankzustände überprüfen (der Wurzel-Referenzhash des neuen Zustands der Datenbank wird unter Berücksichtigung des vorhergehenden Zustands berechnet).
Quelle: opennet.ru
