Guter Grund, um Ihre Abhängigkeiten zu testen: AGPL-Edition

Hier nimmst du den Code unter die BSD-, MIT- und Apache2-Lizenz und bläst nicht den Schneebesen, und dann - bam! - die zweite Verschiebung, und in transitiver Abhängigkeit wird der Code unter AGPL gezeichnet. Wir versuchen, dies im Auge zu behalten und ziehen es vor, zu überholen, anstatt zu unterbieten.



Bevor ich einem meiner Projekte neue Abhängigkeiten hinzufüge, mache ich immer eine grundlegende Überprüfung. Was ich überprüfe (Standardcheckliste):

• Unter welcher Lizenz wird der Code ausgegeben?
• Wer ist der Autor?
• Gibt es schwerwiegende ungelöste Probleme im Error Tracker?
• Gibt es eine Geschichte von schwerwiegenden Fehlern im Error Tracker?
• Wie erfolgt eine Codeüberprüfung für Pull-Quests?

Danach überfliege ich den Code selbst auf der Suche nach etwas offensichtlich Unsicherem oder Bösartigem. Dies ist notwendig, um die Qualität der Codebasis selbst zu spüren. Als nächstes versuche ich, die "braunen M & Ms" zu finden - kleine Details, die auf große Probleme hinweisen können. Und wiederholen Sie rekursiv alle oben genannten mit transitiven Abhängigkeiten. Außerdem überfliege ich den Code jedes Mal, wenn ich die Abhängigkeit aktualisiere.

Dies ist ein ziemlich großer Arbeitsaufwand, der jedoch erforderlich ist, um nicht Opfer von Angriffen wie event-stream zu werden . Und kürzlich wurde ich an einen weiteren guten Grund erinnert, um Abhängigkeiten zu überprüfen. In diesem Moment habe ich die aktiv beworbene Bibliothek von Duo für WebAuthn on Go rezensiert. Sie befindet sich hier: github.com/duo-labs/webauthn .

Alles begann damit, dass ich ein paar "braune M & Ms" bemerkte:

• Die Daten wurden trotz der Tatsache, dass es sich um eine Bibliothek handelt, stdout protokolliert.
• Der Code wurde bevorratet.

Natürlich waren diese kleinen Probleme nur die Vorboten von etwas anderem: Als ich mit der Überprüfung einer der transitiven Abhängigkeiten ( github.com/katzenpost/core/crypto/eddsa ) begann, traf mich der AGPLv3-Lizenzheader .

Dies ist eine schlechte Nachricht für alle, die die WebAuthn-Bibliothek von Duo nutzen möchten. Trotz der Tatsache, dass Duo seine Bibliothek unter BSD lizenziert hat, indem Sie sie auswählen, verknüpfen Sie Ihre Anwendung auch mit der AGPL-Bibliothek. Und gemäß (A) der GPL erstellen Sie auf diese Weise ein „modifiziertes“ Produkt, das den Regeln von Abschnitt 13 der AGPL unterliegt:

Wenn Sie Änderungen am Programm vornehmen, sollte Ihre geänderte Version allen Benutzern, die remote über das Netzwerk mit dem Programm interagieren, ausdrücklich die Möglichkeit bieten (sofern Ihre Version diese Interaktion unterstützt), mit Standard-Software-Kopiertools (trotz) kostenlos auf den Quellcode Ihrer Version zuzugreifen sonstige Bestimmungen dieser Lizenz).

Mit anderen Worten, wenn Sie github.com/duo-labs/webauthn in einer öffentlichen Webanwendung verwendet haben, sollte Ihre Webanwendung jetzt Open Source sein.

Das Ungeheuerlichste an dieser Abhängigkeit ist, dass sie golang.org/x/crypto/ed25519 dupliziert - eine der Quasi - Standard "x" -Bibliotheken von Go.

Tatsächlich ist github.com/duo-labs/webauthn identisch mit dem ursprünglich verwendeten golang.org/x/crypto/ed25519 . Die Substitution erfolgte im Rahmen einer externen Zusammenarbeit mit dem Titel „COSE-Dinge in ihrem eigenen Bereich konsolidieren“ . OKPPublicKeyData.Verify der Übertragung eines Teils des Codes von einer Datei in eine andere änderte diese Pull-Anforderung im OKPPublicKeyData.Verify die Implementierung von OKPPublicKeyData.Verify .

Hier ist das OKPPublicKeyData.Verify , das golang.org/x/crypto/ed25519 verwendet :

 // Verify Octet Key Pair (OKP) Public Key Signature func (k *OKPPublicKeyData) Verify(data []byte, sig []byte) (bool, error) { f := HasherFromCOSEAlg(COSEAlgorithmIdentifier(k.PublicKeyData.Algorithm)) h := f() h.Write(data) return ed25519.Verify(k.XCoord, h.Sum(nil), sig), nil } 

Und hier ist OKPPublicKeyData.Verify , das die AGPL-lizenzierte OKPPublicKeyData.Verify github.com/katzenpost/core/crypto/eddsa verwendet :

 // Verify Octet Key Pair (OKP) Public Key Signature func (k *OKPPublicKeyData) Verify(data []byte, sig []byte) (bool, error) { f := HasherFromCOSEAlg(COSEAlgorithmIdentifier(k.PublicKeyData.Algorithm)) h := f() h.Write(data) var oKey eddsa.PublicKey err := oKey.FromBytes(k.XCoord) if err != nil { return false, err } return oKey.Verify(h.Sum(nil), sig), nil } 

Diese Änderung wurde nicht erklärt. Die Pullrequest-Überprüfung wurde von zwei Duo- Mitarbeitern durchgeführt , von diesen genehmigt und zurückgehalten.

Aus diesem Grund akzeptiere ich keine Anfragen für Pull-Anfragen, die den Code verschieben. Selbst wenn die neue Organisation des Codes besser ist als die vorherige, verschlingt die Zeit, die zum Überprüfen von "Macht die neue Pull-Quest etwas Überflüssiges?" Benötigt wird, zu viel Zeit.

Ich habe eine Warnung bezüglich der Abhängigkeit der Bibliothek von der AGPL-Lizenz veröffentlicht und die Entwickler haben golang.org/x/crypto/ed25519 zurückgegeben . Trotzdem habe ich mich entschieden, github.com/duo-labs/webauthn nicht zu verwenden. Der Großteil der Bibliothek und ihre Abhängigkeiten sind so konzipiert, dass sie WebAuthn-Fehlfunktionen unterstützen, die als Attestierung bezeichnet werden und die ich weniger als null Mal verwenden möchte. Ich habe gerade eine viel einfachere, attestierungsfreie Bibliothek geschrieben, die kleiner als ein Zehntel der oben genannten ist. Bald werde ich den Quellcode öffnen. Die Entwicklung dieser Bibliothek war billiger als die Nutzung der vorhandenen WebAuthn Go-Bibliothek.

Dieser Fall hat mich daran erinnert, warum ich gerne auf Go programmiere. Dank der umfangreichen Standard- und Quasi-Standard-x-Bibliotheken von Go gibt es in meinen Projekten in der Regel nur wenige zusätzliche Abhängigkeiten. Ein guter Ruf und gute Arbeitsabläufe von Go ermöglichen es mir, kein Dampfbad zu nehmen und den Quellcode des Compilers und der Standardbibliotheken nicht noch einmal zu überprüfen. Und trotz der Tatsache, dass ich Rust liebe, bin ich jedes Mal entsetzt, wenn ich mir den Abhängigkeitsbaum ihrer typischen Bibliotheken ansehe: Normalerweise sehe ich Dutzende transitiver Abhängigkeiten, die von obskuren zufälligen Typen aus dem Internet geschrieben wurden, denen ich nicht vertrauen kann. Das Überprüfen all dieser Abhängigkeiten nimmt zu viel Zeit in Anspruch, sodass ich in Rust viel weniger produktiv bin als in Go.

Ein letzter Hinweis: Als Fan von überprüfbaren Datenstrukturen wie Certificate Transparency muss ich die neue Go-Prüfsummen-Datenbank lieben. Die Prüfsummen-Datenbank hilft Ihnen jedoch nicht weiter, wenn Sie keine Zeit damit verbringen, Ihre Abhängigkeiten zu überprüfen. Leider habe ich bereits einen übermäßig begeisterten Go-Benutzer gesehen, der behauptet, die Prüfsummen-Datenbank löse alle Probleme mit dem Abhängigkeitsmanagement. Aber das ist nicht so. Es gibt keine einfachen Möglichkeiten, dies zu beheben, und Sie müssen sich mit der Tatsache abfinden: Von Zeit zu Zeit müssen Sie in Ihren Projekten Abhängigkeitsüberprüfungen durchführen.