Ici, vous prenez le code sous les licences BSD, MIT et Apache2 et ne soufflez pas le fouet, puis - bam! - le deuxième décalage, et en dépendance transitive, le code sous AGPL est tracé. Nous essayons de garder un œil sur cela et préférons dépasser plutôt que sous-terminer.
Avant d'ajouter de nouvelles dépendances à l'un de mes projets, je fais toujours une vérification de base. Ce que je vérifie (liste de contrôle standard):
- Sous quelle licence le code est-il délivré?
- Qui est l'auteur?
- Existe-t-il de graves problèmes non résolus dans le suivi des erreurs?
- Existe-t-il un historique de bogues graves dans le traqueur d'erreurs?
- Comment se déroule une révision du code pour les quêtes Pull?
Après cela, je parcoure le code lui-même à la recherche de quelque chose de manifestement dangereux ou malveillant. Cela est nécessaire pour ressentir la qualité de la base de code elle-même. Ensuite, j'essaie de trouver les
«M&M marron» - des détails mineurs qui peuvent indiquer de gros problèmes. Et répétez récursivement tout ce qui précède avec des dépendances transitives. De plus, je parcourt à nouveau le code chaque fois que je mets à jour la dépendance.
C'est un travail assez important, mais il est nécessaire pour ne pas être victime d'attaques comme le
flux d'événements . Et récemment, on m'a rappelé une autre bonne raison de vérifier les dépendances. À ce moment, je faisais une revue de la
bibliothèque activement annoncée de Duo pour WebAuthn on Go, elle se trouve ici:
github.com/duo-labs/webauthn .
Tout a commencé avec le fait que j'ai remarqué quelques "M&M marron":
- Les données ont été enregistrées dans stdout, bien qu'il s'agisse d'une bibliothèque.
- Le code a été stocké.
Bien sûr, ces problèmes mineurs n'étaient que les signes avant-coureurs de quelque chose de plus: lorsque j'ai commencé un examen de l'une des dépendances transitives (
github.com/katzenpost/core/crypto/eddsa ),
l'en- tête de
licence AGPLv3 m'a rencontré.
C'est une mauvaise nouvelle pour quiconque souhaite utiliser la bibliothèque WebAuthn de Duo. Malgré le fait que Duo ait autorisé sa bibliothèque sous BSD, en la sélectionnant, vous liez également votre application à la bibliothèque AGPL. Et, selon (A) la GPL, de cette façon, vous créez un produit «modifié» qui relève des règles de l'
article 13 de l'AGPL :
Si vous apportez des modifications au programme, votre version modifiée devrait explicitement offrir à tous les utilisateurs qui interagissent avec lui à distance via le réseau (si votre version prend en charge cette interaction) la possibilité d'obtenir un accès gratuit et gratuit au code source de votre version à l'aide d'outils de copie de logiciels standard (malgré à toute autre disposition de cette licence).
En d'autres termes, si vous avez utilisé
github.com/duo-labs/webauthn dans une application Web publique, votre application Web devrait maintenant être open source.
La chose la plus scandaleuse à propos de cette dépendance est qu'elle duplique
golang.org/x/crypto/ed25519 - l'une des
bibliothèques «x» quasi standard de Go.
En fait,
github.com/duo-labs/webauthn est le même que
golang.org/x/crypto/ed25519 utilisé à l'origine. La substitution a eu lieu lors d'une recherche d'une collaboration externe appelée
«Consolider les choses COSE dans leur propre zone» . Dans le processus de transfert d'une partie du code d'un fichier à un autre, cette demande d'extraction a discrètement modifié l'implémentation de
OKPPublicKeyData.Verify .
Voici le
OKPPublicKeyData.Verify qui utilise
golang.org/x/crypto/ed25519 :
Et voici
OKPPublicKeyData.Verify , qui utilise
github.com/katzenpost/core/crypto/eddsa sous licence
AGPL :
Aucune explication n'a été donnée à ce changement. L'examen de la demande de retrait a été effectué par
deux employés de Duo, l'a approuvé et l'a retenu.
C'est pourquoi je n'aime pas accepter les demandes de pull-pull qui déplacent le code. Même si la nouvelle organisation du code est meilleure que la précédente, le temps pris pour vérifier "la nouvelle pull-quest fait-elle quelque chose de superflu" prend trop de temps.
J'ai
publié un avertissement concernant la dépendance de la bibliothèque avec la licence AGPL, et les développeurs ont
renvoyé golang.org/x/crypto/ed25519 . Malgré cela, j'ai décidé de ne pas utiliser
github.com/duo-labs/webauthn . La majeure partie de la bibliothèque et ses dépendances sont conçues pour prendre en charge une caractéristique erronée de WebAuthn appelée attestation, que j'ai moins que zéro envie d'utiliser. Je viens de terminer l'écriture d'une bibliothèque beaucoup plus simple, sans attestation, et elle est inférieure à un dixième de ce qui précède. Bientôt, j'ouvrirai son code source. Le développement de cette bibliothèque est sorti moins cher que la responsabilité d'utiliser la bibliothèque WebAuthn Go existante.
Ce cas m'a rappelé pourquoi j'aime la programmation sur Go. Grâce aux bibliothèques étendues standard et quasi-standard de Go, il y a généralement peu de dépendances supplémentaires dans mes projets. Et la bonne réputation et les procédures d'exploitation de Go me permettent de ne pas m'inquiéter et de ne pas revérifier le code source du compilateur et des bibliothèques standard. Et, malgré le fait que j'aime Rust, je suis horrifié chaque fois que je regarde l'arbre de dépendance de leurs bibliothèques typiques: généralement, je vois des dizaines de dépendances transitives écrites par des mecs aléatoires obscurs d'Internet auxquels je n'ai aucune raison de faire confiance. La vérification de toutes ces dépendances prend trop de temps, donc je suis beaucoup moins productif dans Rust que Go.
Une dernière remarque: en tant que fan de structures de données vérifiables comme la transparence des certificats, je dois aimer la nouvelle
base de données Go checksum . Cependant, la base de données de somme de contrôle ne vous sera d'aucune utilité si vous ne passez pas de temps à vérifier vos dépendances. Malheureusement, j'ai déjà vu un utilisateur Go trop enthousiaste affirmer que la base de données de contrôle résout tous les problèmes de gestion des dépendances. Mais ce n'est pas le cas. Il n'y a pas de moyen facile de s'en débarrasser, et vous devez accepter le fait: de temps en temps, vous devez faire des revues de dépendance dans vos projets.