Algunos desarrolladores están estropeando el software de código abierto

Una de las cosas más sorprendentes del código abierto no es que produzca un gran software. Es que muchos desarrolladores dejan de lado sus egos para crear grandes programas con la ayuda de otros. Ahora, sin embargo, un puñado de programadores está poniendo sus propias preocupaciones por encima del bien de muchos y potencialmente arruinando el software de código abierto para todos.

Por ejemplo, Brandon Nozaki Miller, encargado del mantenimiento del administrador de paquetes de JavaScript, RIAEvangelist, escribió y publicó un paquete de código fuente npm de código abierto llamado Peacenotwar. Hizo poco más que imprimir un mensaje de paz en los escritorios. Hasta ahora, tan inofensivo. 

Miller luego insertó un código malicioso en el paquete para sobrescribir los sistemas de archivos de los usuarios si su computadora tenía una dirección IP de Rusia o Bielorrusia. Luego lo agregó como una dependencia a su popular nodo-ipc programa y caos instantáneo! Numerosos servidores y PC dejaron de funcionar cuando se actualizaron al código más nuevo y luego se borraron las unidades de sus sistemas. 

defensa de Miller, “Todo esto es público, documentado, con licencia y de código abierto.”, no aguanta. 

Liran Tal, el snyk El investigador que descubrió el problema dijo: “Incluso si el acto deliberado y peligroso [es] percibido por algunos como un acto legítimo de protesta, ¿Cómo se refleja eso en la reputación futura del mantenedor? y participación en la comunidad de desarrolladores? ¿Se volvería a confiar en este mantenedor para que no haga un seguimiento de actos futuros en acciones tan agresivas o incluso más agresivas para cualquier proyecto en el que participe? 

Miller no es un excéntrico al azar. Ha producido una gran cantidad de código bueno, como node-ipc, y Servidor HTTP de nodo. Pero, ¿puedes confiar en que alguno de sus códigos no sea malicioso? Si bien él lo describe como “no malware, [sino] protestware que está completamente documentado”, otros venenosamente no están de acuerdo. 

Como escribió un programador de GitHub: "Lo que sucederá con esto es que los equipos de seguridad de las corporaciones occidentales que no tienen absolutamente nada que ver con Rusia o la política comenzarán a ver Software gratuito y de código abierto como vía para los ataques a la cadena de suministro (lo cual es totalmente) y simplemente comiencen a prohibir el software gratuito y de código abierto, todo el software gratuito y de código abierto, dentro de sus empresas”. 

Como escribió otro desarrollador de GitHub con el identificador nm17: "El factor de confianza de código abierto, que se basó en la buena voluntad de los desarrolladores, ahora prácticamente se ha ido, y ahora, cada vez más personas se dan cuenta de que algún día, su biblioteca/aplicación puede ser explotada para hacer/decir lo que sea que algún desarrollador aleatorio en Internet pensó. fue lo correcto que hicieron'”.

Ambos hacen puntos válidos. Cuando no puede usar el código fuente a menos que esté de acuerdo con la postura política de su creador, ¿cómo puede usarlo con confianza? 

El corazón de Miller puede estar en el lugar correcto: ¡Slava Ukraini! — pero, ¿el software de código abierto infectado con una carga maliciosa es la forma correcta de proteger la invasión rusa de Ucrania? No, no es. 

El método de código abierto solo funciona porque confiamos unos en otros. Cuando se rompe esa confianza, sin importar la causa, entonces se rompe el marco fundamental del código abierto. Como dijo Greg Kroah-Hartman, el mantenedor del kernel de Linux para la rama estable, cuando los estudiantes de la Universidad de Minnesota intentaron deliberadamente insertar código incorrecto en el kernel de Linux para un experimento en 2021, dijeron: “Lo que están haciendo es un comportamiento malicioso intencional y no es aceptable y es totalmente poco ético”.

La gente ha argumentado durante mucho tiempo que el código abierto también debería incluir disposiciones éticas. Por ejemplo, 2009 Licencia pública general de excepción (eGPL), una revisión de la GPLv2, trató de prohibir que las "excepciones", como los usuarios y proveedores militares, usaran su código. Falló. Otras licencias como la Licencia JSON con su cláusula dulcemente ingenua "el software se utilizará para el bien, no para el mal" todavía está presente, pero nadie la hace cumplir.  

Más recientemente, la activista y desarrolladora de software Coraline Ada Ehmke presentó una licencia de código abierto que requiere que sus usuarios actúen moralmente. Específicamente, ella licencia hipocrática añadido a la Licencia de código abierto del MIT una cláusula que dice: 

“El software no puede ser utilizado por individuos, corporaciones, gobiernos u otros grupos para sistemas o actividades que pongan en peligro, dañen o amenace de otra manera de manera activa y consciente el bienestar físico, mental, económico o general de personas o grupos desfavorecidos en violación de la Declaración Universal de los Derechos Humanos de las Naciones Unidas”.

Suena bien, pero no es de código abierto. Verá, el código abierto es en sí mismo una posición ética. Su ética está contenida en la Fundación de Software Libre (FSF)es Cuatro libertades esenciales. Esta es la base de todas las licencias de código abierto y su filosofía central. Como el experto legal en código abierto y profesor de derecho de Columbia, Eben Moglen, dijo en ese momento que las licencias éticas no pueden ser software libre o licencias de código abierto: 

"libertad cero, el derecho a ejecutar el programa para cualquier propósito, ocupa el primer lugar en las cuatro libertades porque si los usuarios no tienen ese derecho con respecto a los programas de computadora que ejecutan, en última instancia no tienen ningún derecho sobre esos programas. Los esfuerzos para dar permiso solo para buenos usos, o para prohibir los malos a los ojos del licenciante, violan el requisito de proteger la libertad cero”. 

En otras palabras, si no puede compartir su código por algún motivo, su código no es verdaderamente de código abierto. 

Otro argumento más pragmático acerca de prohibir que un grupo use software de código abierto es que bloquear algo como una dirección IP es una brocha muy amplia. Como Florian Roth, empresa de seguridad Sistemas NextronJefe de Investigación, quien consideró “deshabilitar mis herramientas gratuitas en los sistemas con ciertas configuraciones de idioma y zona horaria”, finalmente decidió no hacerlo. ¿Por qué? Porque al hacerlo, “también deshabilitaríamos las herramientas en sistemas de críticos y librepensadores que condenan las acciones de sus gobiernos”. 

Desafortunadamente, no son solo las personas que intentan usar el código abierto por lo que ven como un propósito ético superior las que están causando problemas al software de código abierto. 

A principios de este año, el desarrollador de JavaScript Marak Squires saboteó deliberadamente sus oscuras pero vitalmente importantes bibliotecas de Javascript de código abierto 'colors.js' y 'faker.js'. ¿El resultado? Decenas de miles de programas JavaScript explotaron.

¿Por qué? Todavía no está del todo claro, pero en una publicación de GitHub eliminada desde entonces, Squires escribió: "Respetuosamente, Ya no voy a apoyar a Fortune 500 (y otras empresas de menor tamaño) con mi trabajo gratuito. No hay mucho más que decir. Aproveche esta oportunidad para enviarme un contrato anual de seis cifras o bifurcar el proyecto y hacer que alguien más trabaje en él”. Como se puede imaginar, este intento de chantajear su camino hacia un cheque de pago no funcionó tan bien para él. 

Y luego están las personas que deliberadamente colocan malware en su código de fuente abierta por diversión y ganancias. Por ejemplo, la empresa de seguridad DevOps JFrog descubrió 17 nuevos paquetes maliciosos de JavaScript en el repositorio de NPM que atacan y roban deliberadamente los tokens de Discord de un usuario. Estos se pueden utilizar en el Discord plataforma de comunicaciones y distribución digital.

Además de crear nuevos programas maliciosos de código abierto que parecen inocentes y útiles, otros atacantes están tomando software antiguo y abandonado y reescribiéndolo para incluir puertas traseras para robar criptomonedas. Uno de esos programas fue event-stream. Tenía un código malicioso insertado para robar billeteras de bitcoin y transferir sus saldos a un servidor de Kuala Lumpur. Ha habido varios episodios similares a lo largo de los años.

Con cada movimiento de este tipo, la fe en el software de código abierto se desgasta. Dado que el código abierto es absolutamente vital para el mundo moderno, esta es una pésima tendencia. 

¿Qué podemos hacer al respecto? Bueno, por un lado, debemos considerar con mucho cuidado cuándo, si alguna vez, debemos bloquear el uso de código fuente abierto. 

Más prácticamente, debemos empezar a adoptar el uso de Fundación Linux Intercambio de datos de paquetes de software (SPDX) y Lista de materiales de software (SBOM). Juntos, estos nos dirán exactamente qué código estamos usando en nuestros programas y de dónde viene. Entonces, seremos mucho más capaces de tomar decisiones informadas.

Hoy en día, con mucha frecuencia las personas usan código fuente abierto sin saber exactamente lo que están ejecutando o verificar si hay problemas. Asumen que todo está bien con eso. Eso nunca ha sido una suposición inteligente. Hoy en día, es francamente tonto. 

Incluso con todos estos cambios recientes, el código abierto sigue siendo mejor y más seguro que las alternativas de software propietario de caja negra. Pero debemos revisar y verificar el código en lugar de confiar ciegamente en él. Es lo único inteligente que se puede hacer en el futuro.

Historias relacionadas: