Autor: noticias

En marzo de 2016 ocurrió un suceso insólito que puso en evidencia la fragilidad de nuestra infraestructura digital: un sencillo y poco conocido paquete ‘open source’ compuesto de tan sólo 11 líneas en JavaScript, fue eliminado por su autor del repositorio NPM (una referencia para los programadores web de todo el mundo), y eso bastó para que buena parte del ecosistema de desarrollo web colapsara durante varias horas. ¿Cómo fue posible que algo tan pequeño tenga consecuencias tan enormes?

La historia del paquete left-pad lo explica todo. El paquete left-pad tenía una función muy simple: agregar caracteres a la izquierda de una cadena de texto para que alcanzara una longitud específica: por ejemplo, convertir el número ‘7’ en ‘007’, una tarea trivial que cualquier programador podría escribir en minutos.

Sin embargo, precisamente por su trivialidad, tenía sentido prescindir de reescribir las mismas 11 líneas una y otra vez, por lo que el paquete que las contenía fue ampliamente adoptado como dependencia en otros proyectos, muchos de ellos fundamentales en el ecosistema JavaScript: Babel, Webpack, React… entre muchos otros.

En la práctica, el correcto funcionamiento de millones de proyectos terminó dependiendo, directa o indirectamente, de este pequeño fragmento de código.

El detonante: una disputa por un nombre

Azer Koçulu, el desarrollador que mantenía left-pad (y otros muchos paquetes), se vio envuelto en una disputa con la empresa Kik Messenger: ésta reclamaba para sí el nombre del paquete ‘kik’ en NPM, pese ser anterior a la fundación de dicha compañía. Todo se torció cuando los responsables del repositorio favorecieron la postura de Kik y expropiaron al desarrollador de la propiedad del nombre para transferírsela a la empresa sin el consentimiento de Koçulu.

En protesta, Koçulu decidió retirar todos sus paquetes de NPM, una lista compuesta de casi 300… que incluía al ya mencionado left-pad. El problema, como decíamos, era que muchos proyectos dependían de left-pad para poder construirse o instalarse. Así que, cuando el paquete desapareció del repositorio, innumerables desarrolladores de todo el mundo comenzaron a ver errores al intentar compilar o ejecutar sus aplicaciones.

En Genbeta

El gestor de paquetes NPM, usado para difundir malware entre los desarrolladores de aplicaciones NodeJS

Durante varias horas, amplios sectores del ecosistema de JavaScript quedaron paralizados. No es que las aplicaciones web dejaran de funcionar: pero nuevas instalaciones y despliegues fallaban, especialmente en entornos de integración continua (CI/CD). Y ‘NPM’ tuvo que reaccionar reinstaurando (de nuevo a espaldas de Koçulu) el paquete con el mismo nombre, algo que normalmente no está permitido, debido a la urgencia de la situación.

En definitiva, un episodio bastante movido que terminó generando todo un debate ético y técnico sobre la gobernanza del software libre.

¿Qué aprendimos? (¿O qué deberíamos haber aprendido?)

Este incidente puso de relieve varias lecciones clave sobre el desarrollo de software moderno:

• La interdependencia extrema: un software aparentemente insignificante puede estar en el corazón de cientos o miles de otros sistemas.
• Falta de redundancia: muchas empresas dependían de servidores externos sin tener copias locales de sus dependencias.
• Gobernanza y control: los conflictos entre desarrolladores independientes y plataformas centralizadas como NPM pueden tener consecuencias técnicas de gran alcance.
• Licencias abiertas y sus límites: left-pad estaba bajo la licencia WTFPL (‘Do What The Fuck You Want With It’, algo así como «Haz lo que te dé la pulcra gana con esto»…y sí, existe), que permite hacer prácticamente cualquier cosa con el código. Esto facilitó su reinstauración, pero también ilustró los riesgos de tener software crítico sin responsabilidad clara.

El caso de left-pad nos recuerda que gran parte de la tecnología que usamos a diario se sostiene sobre proyectos de código abierto mantenidos por personas que, muchas veces, no reciben compensación alguna. Esta situación sigue vigente hoy. Por eso, además de utilizar software libre, es crucial apoyarlo: económicamente, con tiempo o al menos con reconocimiento.

Porque, al final, todo Internet puede terminar dependiendo de un puñado de líneas de código escritas por un desarrollador solitario en su tiempo libre.

Pese a ello, pocos fueron los que aprendieron la lección. Esa falta de aprendizaje quedó patente con otro incidente aún más grave: Log4Shell.

Log4Shell: cuando todo volvió a fallar

En diciembre de 2021, se descubrió una vulnerabilidad crítica (CVE-2021-44228) en Log4J, una biblioteca de código abierto usada para registrar eventos en aplicaciones Java. Este fallo permitía la ejecución remota de código, lo que convertía a millones de servidores en objetivos accesibles para los atacantes.

La respuesta fue veloz: en apenas 24 horas, los mantenedores —tres voluntarios que trabajaban en su tiempo libre— lanzaron un parche. Sin embargo, el escándalo fue otro: ¿cómo era posible que una biblioteca esencial para empresas multimillonarias estuviera mantenida por tres personas no remuneradas, personas que tuvieron que pasarse toda una noche sin dormir para evitar problemas masivos de ciberseguridad?

Volvía a reverlarse un patrón familiar: el corazón tecnológico de las mayores corporaciones del mundo late gracias a esfuerzos individuales poco reconocidos, y peor aún, precarizados: estos desarrolladores, lejos de recibir apoyo, fueron víctimas de ataques injustos mientras intentaban contener el desastre.

En Genbeta

El respaldo a los proyectos ‘open source’, motivo de una cumbre en la Casa Blanca convocada para evitar casos como el de Log4Shell

¿Cómo evitar el próximo «left-pad»?

La caída de left-pad debía habernos enseñado sobre la fragilidad del ecosistema de software libre (que es como decir el ecosistema de todo Internet). Pero no aprendimos. En lugar de reforzar los cimientos del open source, las grandes tecnológicas continuaron capitalizando sus beneficios sin invertir proporcionalmente en su sostenimiento.

La solución no pasa solo por hacer forks o tener listas copias de respaldo de los paquetes. Amplios sectores del mundo del código abierto y/o el desarrolló web piden tomar medidas:

1. Financiación estable: patrocinios, fondos públicos y modelos sostenibles que remuneren el mantenimiento.
2. Gobernanza comunitaria: evitar que proyectos críticos dependan de una sola persona.
3. Auditoría y mantenimiento continuo: establecer estándares mínimos de seguridad, testing y actualización.
4. Cultura de la dependencia consciente: no importar paquetes triviales solo por conveniencia.

Imagen | Marcos Merino mediante IA
En Genbeta | Qué fue de los programadores que hace dos años trabajaron gratis para evitar pérdidas millonarias a grandes tecnológicas

–
La noticia

Alguien borró 11 líneas de código open source y rompió Internet. El caso dejó varias lecciones de las que nadie tomó nota

fue publicada originalmente en

Genbeta

por
Marcos Merino

.