Aquí tomas el código bajo las licencias BSD, MIT y Apache2 y no tocas el batidor, y luego - ¡bam! - el segundo turno, y en dependencia transitiva se dibuja el código bajo AGPL. Intentamos vigilar esto y preferimos adelantar en lugar de terminar por debajo.
Antes de agregar nuevas dependencias a cualquiera de mis proyectos, siempre hago una verificación básica. Lo que verifico (lista de verificación estándar):
- ¿Bajo qué licencia se emite el código?
- Quien es el autor
- ¿Hay problemas serios sin resolver en el rastreador de errores?
- ¿Hay un historial de errores graves en el rastreador de errores?
- ¿Cómo se realiza una revisión de código para las misiones de extracción?
Después de eso, hojeo el código mismo en busca de algo obviamente inseguro o malicioso. Esto es necesario para sentir la calidad de la base del código en sí. A continuación, trato de encontrar los
"M & Ms marrones" : detalles menores que pueden indicar grandes problemas. Y repita recursivamente todo lo anterior con dependencias transitivas. Además, una vez más hojeo el código cada vez que actualizo la dependencia.
Esta es una cantidad de trabajo bastante grande, pero es necesaria para no ser víctima de ataques como
el flujo de eventos . Y recientemente, recordé otra buena razón para verificar las dependencias. En ese momento estaba haciendo una revisión de la
biblioteca publicitada activamente de Duo para WebAuthn on Go, que se encuentra aquí:
github.com/duo-labs/webauthn .
Todo comenzó con el hecho de que noté algunos "M&M marrones":
- Los datos se registraron en stdout, a pesar de que se trata de una biblioteca.
- El código fue almacenado.
Por supuesto, estos problemas menores fueron solo los precursores de algo más: cuando comencé una revisión de una de las dependencias transitivas (
github.com/katzenpost/core/crypto/eddsa ),
el encabezado de la
licencia AGPLv3 se reunió conmigo.
Estas son malas noticias para cualquiera que quiera usar la biblioteca WebAuthn de Duo. A pesar de que Duo licencia su biblioteca bajo BSD, seleccionándola, también vincula su aplicación con la biblioteca AGPL. Y, de acuerdo con (A) la GPL, de esta manera usted crea un producto "modificado" que cae bajo las reglas de la
sección 13 de la AGPL :
Si realiza cambios en el programa, su versión modificada debería ofrecer explícitamente a todos los usuarios que interactúan con él de forma remota a través de la red (si su versión admite esta interacción) la oportunidad de obtener acceso gratuito y gratuito al código fuente de su versión utilizando herramientas de copia de software estándar (a pesar de a cualquier otra disposición de esta Licencia).
En otras palabras, si utilizó
github.com/duo-labs/webauthn en una aplicación web pública, su aplicación web ahora debería ser de código abierto.
Lo más escandaloso de esta dependencia es que duplica
golang.org/x/crypto/ed25519 , una de las
bibliotecas cuasi estándar "x" de Go.
De hecho,
github.com/duo-labs/webauthn es lo mismo que
golang.org/x/crypto/ed25519 originalmente utilizado. La sustitución tuvo lugar durante una búsqueda de una colaboración externa llamada
"Consolidar las cosas COSE en su propia área" . En el proceso de transferir parte del código de un archivo a otro, esta solicitud de extracción cambió silenciosamente la implementación de
OKPPublicKeyData.Verify .
Aquí está el
OKPPublicKeyData.Verify que usa
golang.org/x/crypto/ed25519 :
Y aquí está
OKPPublicKeyData.Verify , que utiliza
github.com/katzenpost/core/crypto/eddsa con licencia
AGPL :
No se dio ninguna explicación a este cambio. La revisión de solicitud de extracción fue realizada por
dos empleados de Duo, la aprobó y la detuvo.
Por eso no me gusta aceptar solicitudes de solicitudes de extracción que mueven el código. Incluso si la nueva organización del código es mejor que la anterior, el tiempo necesario para comprobar "¿la nueva búsqueda de extracción hace algo superfluo" consume demasiado tiempo.
Publiqué una advertencia sobre la dependencia de la biblioteca con la licencia AGPL, y los desarrolladores
devolvieron golang.org/x/crypto/ed25519 . A pesar de esto, decidí no usar
github.com/duo-labs/webauthn . La mayor parte de la biblioteca y sus dependencias están diseñadas para admitir el error de WebAuthn llamado atestación, que tengo menos de cero deseo de usar. Acabo de terminar de escribir una biblioteca mucho más simple y libre de certificación, y es más pequeña que una décima parte de lo anterior. Pronto abriré su código fuente. El desarrollo de esta biblioteca resultó más barato que la responsabilidad de usar la biblioteca existente de WebAuthn Go.
Este caso me recordó por qué me gusta programar en Go. Gracias a las extensas bibliotecas estándar y cuasi-estándar "x" de Go, generalmente hay pocas dependencias adicionales en mis proyectos. Una buena reputación y los procedimientos operativos de Go me permiten no tomar un baño de vapor y no verificar el código fuente del compilador y las bibliotecas estándar. Y, a pesar del hecho de que amo a Rust, me horrorizo cada vez que miro el árbol de dependencia de sus bibliotecas típicas: generalmente veo docenas de dependencias transitivas escritas por oscuros tipos aleatorios de Internet en los que no tengo motivos para confiar. Verificar todas estas dependencias lleva demasiado tiempo, por lo que soy mucho menos productivo en Rust que en Go.
Una nota final: como fanático de las estructuras de datos verificables como Certificate Transparency, me encanta la nueva
base de datos de suma de verificación Go . Sin embargo, la base de datos de suma de comprobación no le servirá de nada si no dedica tiempo a verificar sus dependencias. Desafortunadamente, ya he visto a un usuario de Go demasiado entusiasta alegando que la base de datos de suma de verificación resuelve todos los problemas con la gestión de dependencias. Pero esto no es así. No hay formas fáciles de deshacerse de esto, y debe aceptar el hecho: de vez en cuando necesita hacer revisiones de dependencia en sus proyectos.