FakerJS es una librería de JavaScript que tiene más de 27mil descargas semanales y es usada en múltiples proyectos de código. El 5 de enero dejó de funcionar inesperadamente, lo que creó un efecto dominó en los proyectos que utilizaban esta librería. La causa fue que el creador de FakerJS, de forma intencionada y a modo de protesta, creó un commit llamado “endgame”, que hizo que la librería se averiara. Agregó a su código un comentario con la pregunta “¿Qué le pasó a Aaron Swartz?”, entre otras cosas. Aaron Swartz fue un activista de Internet, enjuiciado por el gobierno norteamericano, que se suicidó en el año 2013.
FakerJS no fue la única librería afectada, sino también otra llamada ColorJS (con millones de usuarios) creada por el mismo creador de FakerJS. En ella, añadió un ciclo infinito para corromper su funcionamiento y causar que genere caracteres extraños en los repositorios que la utilicen.
Como consecuencia, proyectos como Amazon Cloud Kit, NestJS, librerías de Azure y cientos de otros proyectos se vieron afectados y tuvieron que hacer reparaciones de emergencia.
¿Cuál fue la razón?
Se sabe poco de las verdaderas razones del creador de los repositorios, Marak Squires, para tomar estas medidas, pero el programador declaró abiertamente:
respetuosamente, ya no apoyaré a las empresas Fortune 500 con mi trabajo gratuito
Como respuesta, GitHub tomó acción y suspendió la cuenta del autor y devolvió los repositorios a una versión estable antes de que se realicen los cambios dañinos. Marak respondió con el siguiente tweet:
Esta es una acción que está permitida dentro de las políticas y condiciones que GitHub tiene para sus usuarios.
Si embargo, GitHub cambió la descripción de este punto de una forma más elegante debido a la situación presentada.
La fragilidad del open source.
Este incidente trae a discusión un tema de vital importancia y es la fragilidad que puede tener el ecosistema open source. Si bien, por años nos hemos beneficiado de proyectos open source como Angular y React, que tienen a empresas gigantescas como Google y Facebook detrás, hay otras iniciativas que dependen exclusivamente del patrocinio voluntario. Proyectos como VueJS, Django, Webpack, FastAPI entre otros, dependen de patrocinios para mantenerse con vida.
Esta misma fragilidad en las dependencias que usamos para construir nuestros sistemas también puede ser un problema de seguridad, como fue el caso del incidente con event-stream en el año 2018, cuando fue infectada con código malicioso. El ataque fue diseñado para afectar solamente a un proyecto en particular: Copay, una billetera electrónica de BitCoins.
Con una práctica de ingeniería social, un usuario se hizo pasar por contribuidor con buenas intenciones y aportó código útil dentro de la librería, pero internamente le inyectó código malicioso y, de repente, todos los proyectos que se apoyaban en ella se vieron afectados. Mucha presión cayó sobre el creador, dominictarr, quien aceptó una contribución externa y expresó que ya no seguiría manteniendo esa librería.
¿Entonces ya no uso dependencias?
Eso no es del todo posible, ya que la mayoría de nuestros sistemas funcionan sobre abstracciones y en una red de confianza, lo cual nos hace más ágiles y productivos. Sin embargo, es una clara muestra del efecto dominó que un error puede causar. El open source es un beneficio tanto para personas como para empresas, pero también necesita de apoyo. Es de interés de todos mantenerlo actualizado y seguro.
Una forma que tenemos como desarrolladores es contribuir con PRs, reportar issues, entre otras acciones, pero eso no es suficiente. Se necesita encontrar una manera de financiar el trabajo de los involucrados. GitHub recientemente creó un método para apoyar directamente a esos proyectos con el botón “Sponsor”. A esto se unen también plataformas como Open Collective, que tiene implementada una función para aportar a proyectos que consideramos valiosos y no queremos que se queden sin soporte algún día.
Me alegra mencionar que esto también despertó la conversación dentro del equipo de ingeniería de Platzi, donde estamos buscando la forma de apoyar a proyectos que nos ayudan a cumplir nuestra misión.
Dime en los comentarios ¿Te viste afectado por estas librerías? ¿Piensas que Github tomo las acciones correctas? ¿Qué opinas sobre la fragilidad del open source? 👇
Curso de Backend con Node.js: API REST con Express.js
