Buena parte de la ciberseguridad se basa en la criptografía, en el arte de proteger la información transformándola de tal modo que solo podrá verla quien esté autorizado. Y para que la criptografía funcione hay fundamentalmente dos fórmulas. En una, pagas para que una autoridad verifique tu identidad. En otra, libre y gratuita, tu identidad es garantizada por otros pares que te conocen o la han comprobado de alguna forma. Esta infraestructura se llama genéricamente OpenPGP. Se utiliza en asuntos tan serios como la firma de programas en las distribuciones Linux más populares, además de plataformas de correo seguro o para la comunicación de vulnerabilidades críticas.
Para que funcione de forma global y distribuida OpenPGP depende de unos servidores que permiten que se localicen las claves de identidad de las personas u organismos con los que nos queremos comunicar. Y para poder interactuar con estos “listines telefónicos”, poner orden (porque todo el mundo puede darse de alta) y redistribuir y la carga, se usa a su vez un servidor único que tiene su propia clave en la que todo el mundo confía. Kristian Fiskerstrand, desde 2006, es la única persona que controla el certificado que garantiza la identidad y comunicación cifrada con este sistema.
Un día, a mediados de 2020, a Todd Fleisher, que maneja uno de esos “listines”, se le caducó el certificado que le permitía comunicarse con ese servidor central y por tanto sincronizarse con la infraestructura OpenPGP. Buscó a Kristian desesperadamente durante un mes para que le firmara el nuevo certificado y continuar con la operativa. El tiempo corría en su contra. Kristian no daba señales de vida ni por correo ni por redes sociales. Tuvo que recurrir a un parche para continuar con su servidor, pero si el resto de listines comenzaban a caducar, OpenPGP dejaría de tener sentido. Tras hacerse pública la llamada, Kristian respondió en la lista oficial de correo que había estado en otros asuntos últimamente (y dijo, textualmente, que le había “sentado muy bien” esa desconexión). Finalmente renovó el certificado. Si hubiera tardado algo más, habrían caducado el resto de los servidores poco a poco.
Este episodio evidencia una realidad agridulce en el mundo del software libre: el ideal romántico de que individuos altruistas puedan sostener proyectos vitales para la infraestructura digital global. Y hay más casos.
Nos vamos a finales de 2001. Log4j es un pequeño componente de software libre, gratuito y abierto que se utiliza en millones de aplicaciones y servicios, libres y privados, incluidos productos y grandes sistemas de corporaciones tecnológicas, incluyendo algunas de las BigTech habituales, entre muchas otras. Hasta que un ingeniero de cloud de una de esas empresas encontró un grave fallo de seguridad en este componente Java que obligó a todos los grandes fabricantes que lo usaban a generar un parche de urgencia en sus productos y sacudió los cimientos de Internet dada su popularidad y facilidad para aprovechar el problema.
Log4j era mantenido exclusivamente por Ralph Goers, que trabaja (y trabajaba en aquel momento) a tiempo completo como arquitecto de software. Log4j y otros de sus proyectos de código abierto están relegados a su tiempo libre. Confiesa en su perfil que sueña con trabajar en ello a tiempo completo y por tanto pide apoyo económico para que esto suceda. Cuando ocurrió el incidente contaba con tres espónsores altruistas que le proporcionaban un puñado de dólares al año. Después de darse a conocer la vulnerabilidad se unieron puntualmente muchos más, pero hoy cuenta solo con doce mecenas regulares que donan para que mantenga un proyecto tan importante.
XZ comprime datos, y es usada a su vez por otros muchísimos programas en Linux. Mayo del 2022. Lasse Colin no podía mantener en solitario el código de la herramienta y desde hacía algún tiempo había confiado su desarrollo a una persona que hasta entonces le echaba un cable en el mantenimiento. Collin, agradecido y dado el buen hacer del “desconocido”, le permitió poco a poco tomar el control del programa, abierto y libre. El desconocido lo hizo estupendamente hasta finales de 2003, cuando poco a poco y con increíble paciencia consiguió culminar su plan. En febrero de 2024 se descubrió que había introducido una muy sofisticada puerta trasera en XZ que le hubiera permitido entrar prácticamente en cualquier sistema Linux sin permiso.
Existen decenas de ejemplos como los anteriores, que apenas trascienden a la opinión pública. Quizás pensamos que todo el software libre puede usarse tranquilamente por organizaciones o grandes empresas, y que ahí es auditado. Nos convencemos de que otros ojos están velando para que todo funcione, sea seguro y no existan estos problemas. Pero como se suele decir en ciberseguridad (una conocida tira cómica lo plasmó irónicamente hace años) a veces no somos conscientes de que la “infraestructura de internet puede depender de una pequeña pieza de código que un altruista señor de Nebraska lleva manteniendo desde 2003”.
Estos son solo tres ejemplos de puntos críticos en manos de una sola persona que voluntariamente programó un componente que se popularizó tanto como para ser ubicuo o aprovechado en el software de grandes empresas (porque su licencia libre y abierta lo permite) y sigue manteniéndolo porque el propio autor es quien realiza el mejor trabajo. Algo muy de los 90, pero anacrónico en nuestros días. Esta fórmula tan popular es, como se ha demostrado tantas veces, propenso a errores, fallos y muy dependiente. Romántico, pero poco práctico.
El software libre mantiene el mundo en marcha. Su filosofía es esencial para innovar y evolucionar la tecnología. Pero no olvidemos que también requiere financiación para que no sólo una persona, sino un equipo, pueda dedicarle el tiempo correspondiente. Un sistema crítico no puede sostenerse gracias a buenas voluntades. Hace falta inversión (y no sólo donaciones), colaboraciones (más allá de las buenas palabras), infraestructuras y personas. Sobre todo, personas que pueda vivir de ello. No se puede depender de, literalmente, un técnico para una parte crítica del sistema porque pone en juego toda su funcionalidad. No es deseable en una empresa (aunque a veces ocurre) y tampoco en ecosistema del software libre. No se puede estar buscando a Kristian desesperadamente, o acordarse de Ralph solo cuando comete un error.