La presión
(daniel.haxx.se)- El mantenimiento de curl se ha convertido en un trabajo de tiempo completo que combina interés público, desafío de ingeniería y objetivos de calidad, y ha continuado en torno a 50 horas por semana
- curl es una biblioteca y herramienta de transferencia con una base instalada de unos 30 mil millones, y pesa mucho la carga de evitar que fallas de seguridad se propaguen a los usuarios
- Actualmente, la entrada de reportes de seguridad es 4 a 5 veces mayor que en 2024 y el doble que en 2025, con más de un reporte por día en promedio, por lo que requiere atención inmediata
- El manejo de seguridad incluye validar afirmaciones, evaluar la severidad, escribir parches, identificar cuándo se introdujeron, redactar avisos y comunicarse con investigadores y el equipo de seguridad
- Ya hay 12 vulnerabilidades confirmadas en espera para el próximo lanzamiento, y aun bajo una presión sin precedentes quedan en evidencia los límites del apoyo en financiamiento y personal
La responsabilidad sobre curl y el mantenimiento a largo plazo
- El trabajo de código abierto no continúa por dinero ni por una vida glamorosa, sino por su significado social, su valor público y el desafío de ingeniería de hacer que funcione para todos
- El trabajo en curl pasó a ser de tiempo completo desde 2019, y normalmente ocupa unas 50 horas semanales, extendiéndose entre el día y la noche, entre semana y fines de semana
- El objetivo de curl es convertirse en la mejor biblioteca y herramienta de transferencia posible, y en un proyecto de primer nivel en calidad, rendimiento y seguridad dentro del código abierto
- curl no es el proyecto de una sola persona, y sin los integrantes del equipo no existiría el curl actual, pero mucha gente sigue vinculándolo fuertemente con Daniel Stenberg como individuo
- Las críticas a curl se reciben como críticas a decisiones y elecciones que uno apoyó o tomó directamente, y curl se ha convertido en un proyecto personal que cambió la vida para siempre
- A finales de 2026, el proyecto curl cumplirá 30 años, y se menciona que el número de instalaciones de curl en el mundo ronda los 30 mil millones
Cambios en el entorno de reportes de seguridad
- En los últimos años, el entorno de reportes de seguridad de curl ha cambiado desde las quejas sobre los LLM tontos hacia los reportes de basura generados por IA, el fin del bug bounty y el caos de alta calidad que comenzó alrededor de marzo de 2026
- Cada vez que se repiten grandes fallas de seguridad en productos de internet, infraestructura de software y código abierto, aumenta la presión por el hecho de que curl está en todas partes y de que algo así no debe ocurrir ni en curl ni a sus usuarios
- El proyecto curl ha ido agregando más revisiones, pruebas y lineamientos, reduciendo poco a poco la posibilidad de que defectos se filtren o hundan el proyecto
Alto nivel de verificación y riesgos persistentes
- Después de que Mythos encontrara solo un problema de baja severidad en su primer escaneo, se repite la evaluación de que curl es uno de los códigos más revisados, sometidos a fuzzing y verificados que se puedan imaginar
- Este estado no es producto del azar ni de la suerte, sino del resultado de décadas de trabajo persistente, atención al detalle y mejora iterativa sin fin
- Que haya mucha revisión y verificación no significa que no existan bugs o problemas de seguridad; curl es código en C de cientos de miles de líneas que realiza redes altamente paralelas sobre múltiples protocolos, sistemas operativos y arquitecturas de CPU
- Cada vez que se descubre un problema, se corrige y se repite el proceso de publicar un parche
- Una base instalada global de unos 30 mil millones significa que curl probablemente está presente varias veces en teléfonos, tabletas, autos, televisores, impresoras, consolas de videojuegos y electrodomésticos de cocina
- En el pasado, los proyectos que hicieron que el mundo ardiera por un tiempo debido a grandes bugs recibieron atención, y algunos obtuvieron financiamiento y personal para contratar a varios ingenieros de tiempo completo
Un volumen de reportes de seguridad sin precedentes
- Actualmente, el ritmo de entrada de reportes de seguridad es 4 a 5 veces mayor que en 2024, el doble que en 2025, y llega más de un reporte por día en promedio
- La calidad de los reportes es mucho más alta que antes, y por lo general están escritos con mucho detalle y extensión
- Como los reportes siguen llegando, deben procesarse en lo posible en cuanto llegan, porque si no se atienden a un ritmo similar al de entrada, la lista de posibles problemas de seguridad sigue acumulándose
- Una lista de posibles problemas de seguridad fuera de control genera una carga mental
- Actualmente, la mayor parte del tiempo se dedica a procesar la lista de incidentes de seguridad reportados en HackerOne
- Las tareas principales incluyen validar afirmaciones, evaluar la severidad, escribir parches, determinar cuándo se introdujo el bug, entender la vulnerabilidad, redactar avisos de seguridad detallados y comunicarse con investigadores de seguridad y con el equipo de seguridad de curl
Presión sobre la salud y el equipo
- Por primera vez, su esposa expresó preocupación por las horas de trabajo y el desequilibrio entre vida y trabajo, y la gente cercana también se preocupa por cómo está manejando esta afluencia masiva y por la posibilidad de agotamiento
- También ha crecido la preocupación por los integrantes del equipo, y quizá pronto sea necesario reducir las horas de trabajo para asegurar algo de respiro
- La situación actual es una presión que ni el proyecto curl ni los integrantes del equipo de seguridad habían experimentado antes
- Atender incidentes de seguridad es una tarea de máxima prioridad que desplaza todo lo demás del proyecto, y no se ignora por sentido de responsabilidad, conciencia y orgullo por el trabajo
- Dado que curl es software desplegado en dispositivos de todo el mundo, existe un fuerte sentido de obligación de corregir los problemas de seguridad que contiene
- Ya existen 12 vulnerabilidades confirmadas cuando aún queda cerca de la mitad del ciclo hasta el lanzamiento programado, lo que significa 12 anuncios de CVE en espera
- Este es un nuevo récord para el proyecto, y significa que antes de que 2026 llegue siquiera a la mitad ya se alcanzarán 30 CVE públicas
- Si esta tendencia continúa, se espera que el número total de CVE publicadas de curl en 2026 sea al menos el doble
El apoyo necesario y los límites estructurales
- A corto plazo, ya hay demasiado trabajo pendiente como para que llegue ayuda inmediata a tiempo
- Si más empresas que usan y dependen de curl o libcurl en software y servicios comerciales aportaran financiamiento, se podría pagar a más desarrolladores para repartir la carga de trabajo
- Otra vía posible de apoyo es mediante contratos de soporte que hagan que los empleadores paguen los costos
- Ya existen clientes que brindan este tipo de apoyo, por lo que algunos integrantes pueden trabajar en curl de tiempo completo
- Aun así, no hay expectativa de que ocurra pronto un cambio significativo en esta área, y es probable que incluso en esta situación sin precedentes y en una fase más difícil, al final tengan que atravesar la tormenta por su cuenta
- El proyecto curl no pertenece a ninguna empresa ni forma parte de ninguna organización paraguas
- Esta estructura a veces genera escasez de recursos, pero al mismo tiempo ofrece la mayor libertad y flexibilidad posible
- El criterio de actuación del proyecto está orientado a hacer que curl sea lo mejor posible para el mundo y para sus usuarios
Lo positivo y el estado actual
- Corregir bugs y problemas es en sí mismo algo bueno, y cada problema reportado pronto se convierte en un incidente corregido
- Cuantos más reportes llegan, mejor producto se vuelve curl
- Todas las vulnerabilidades de curl encontradas en los últimos años han sido evaluadas con severidad LOW o MEDIUM, y casi no se han encontrado vulnerabilidades muy graves
- Eso no significa que no vuelva a aparecer una de nivel HIGH en el futuro, pero al menos sigue siendo algo poco común
- La CVE de curl más reciente de alta severidad fue CVE-2023-38545, publicada en octubre de 2023
- Actualmente, el equipo de curl está bajo presión y a veces puede responder con lentitud
1 comentarios
Opiniones de Lobste.rs
Espero que Daniel y los demás puedan superar bien esta situación difícil sin un gran impacto negativo en su salud o su familia
Aun así, será bastante interesante ver cómo se desarrolla esto. No es la primera vez que un nuevo método de análisis automatizado encuentra de repente muchas vulnerabilidades en varios proyectos FOSS, y ahora se siente parecido a cuando apareció el greybox fuzzing en la década de 2010. Parece haber tres posibles desenlaces: A) un escenario tipo fuzzer en el que los desarrolladores incorporan los LLM al flujo de investigación de seguridad, baja mucho la cantidad de nuevas vulnerabilidades que encuentran los LLM, y se siguen descubriendo las que los LLM no alcanzan. B) algo similar a A, pero después de que los LLM revisan todo, el hallazgo de vulnerabilidades prácticamente se detiene, un escenario donde “los LLM resuelven la investigación de seguridad”. C) un escenario de “la venganza de Tony Hoare” en el que se siguen encontrando vulnerabilidades a una tasa alta en proyectos grandes como curl, y la cantidad de bugs en proyectos de cientos de miles de líneas de código es prácticamente infinita
En una instantánea de una base de código solo puede haber una cantidad finita de bugs de seguridad. Cuando se agote el espacio de búsqueda de bugs de seguridad, la avalancha se calmará, y luego probablemente quedarán algunos bugs que vengan poco a poco de merges de código, nuevos test harnesses o mejoras del modelo
Respecto al escenario C para el proyecto curl, creo que los bugs encontrados fueron de baja gravedad porque ya existía un estándar alto en pruebas de seguridad y técnicas tradicionales de detección de bugs. Eso muestra que la inversión continua en encontrar bugs sigue dando frutos a largo plazo. Da igual qué método de descubrimiento exista hoy o en el futuro
Citando a Marcus Hutchins, esto se parece más a que “encontrar bugs nunca fue el cuello de botella; el cuello de botella fue la decisión de las organizaciones de no invertir en investigadores de seguridad”. Los LLM solo abarataron esa inversión, y las organizaciones siempre pudieron haber invertido más para encontrar más bugs. Al final, es una decisión de política
Las empresas que crean tecnología LLM están destruyendo no solo el mundo natural sino también el mundo del software. Con los precios del hardware disparados, hasta la computación personal misma está amenazada, y también los desarrolladores de código abierto de buena fe que crean porque quieren crear
Parece que hay financiamiento infinito para menospreciar y romper proyectos de código abierto gestionados por comunidades existentes, pero nada de dinero para lidiar con las consecuencias, lo cual resulta interesante
Creo que esto demuestra que Zig tenía razón. Los CVE descubiertos por LLM simplemente no deberían atenderse; que se encargue quien quiera hacerlo
Sé que ese no es exactamente el punto, pero el problema con los CVE de LLM es que probablemente cualquier otra persona que use la misma herramienta encontrará lo mismo. Si de verdad se descubre algo grave, eso significa que más gente podría construir algo dañino a partir de ello
Claro, eso no quiere decir que aplique igual a la avalancha de problemas de baja gravedad o de no seguridad en curl. Aun así, hay que decidir realmente qué issues tienen alta prioridad, y entonces volvemos otra vez al paso 1
Zig sigue en desarrollo activo y, por ejemplo, cada vez que concreta funciones como compilación incremental o I/O asíncrono, es muy probable que introduzca nuevos bugs, mientras al mismo tiempo elimina bugs que existían porque implementaciones anteriores eran incompletas
En esta etapa del desarrollo, si alguien ejecuta algo como Mythos sobre Zig con la idea de “encuentren todos los bugs y no se equivoquen”, saldría una enorme cantidad de reportes, pero es muy probable que el conjunto completo sea, en la práctica, inútil para nosotros. En este momento, el valor principal de los reportes de bugs es que señalan que hay un usuario bloqueado en un caso de uso específico y, si decidimos darle prioridad, podemos destrabar a ese usuario
Eso no significa que este estado vaya a durar para siempre. Muchas funciones importantes del compilador ya se están alineando, y cuando se estabilice, encontrar y corregir todos los bugs será la máxima prioridad. En ese momento, el hecho de que el bug sea conocido pasará a ser importante sin importar cómo se descubrió, pero ese problema se abordará cuando llegue ese momento
Mientras tanto, la política es simplemente prohibir los LLM
Entiendo prohibir contribuciones de LLM, pero no estoy de acuerdo. Una vulnerabilidad de seguridad es una vulnerabilidad sin importar cómo se haya descubierto
Creo que la manera en que lo maneja Daniel es la mejor. Corregir los bugs que se puedan corregir para hacer a los usuarios más seguros, y pedir apoyo dejando claro que el costo es alto. Probablemente él no lea esto, pero también quiero apoyar y recomendar que limite su carga de trabajo para priorizar su salud física y mental. Creo que la mayor parte del mundo lo entenderá, y solo una minoría se quejará
Parece que aquí faltan dos puntos clave. 1) Ni las empresas de LLM ni Project Zero pusieron ese bug de seguridad en el código. 2) Corregir bugs de seguridad no se hace por las empresas de LLM ni por Project Zero, sino por los usuarios. Si se explota un bug de seguridad, quienes sufren son los usuarios
En particular, en el caso de bugs encontrados por LLM, ya hay señales de que otras personas que usan el mismo LLM en varios proyectos de código abierto están enviando reportes duplicados. Por lo tanto, si los defensores se desentienden, hay que asumir que los atacantes también conocerán los bugs descubiertos por LLM
“Envidio a los proyectos que distribuyeron bugs horribles que incendiaron el mundo por un tiempo. Recibieron atención y algunos obtuvieron fondos y respaldo financiero para tener personal y contratar a varios ingenieros de tiempo completo. A veces pienso que quizá nos habría ido mejor si hubiéramos tenido uno de esos”
Esto también pasa en muchos trabajos. A los equipos que fracasan les asignan más gente, mientras que a los equipos que van bien les toca hacer más con menos personal porque no ocurre nada terrible
No sé si aplicaría a proyectos como curl, pero ¿ayudaría una congelación de funcionalidades durante cierto tiempo para concentrarse solo en los reportes entrantes de bugs/CVE?
Si el conjunto de funcionalidades es fijo, la cantidad de bugs/CVE potenciales es finita, y al ir corrigiéndolos parecería acercarse a 0
En cualquier caso, les deseo suerte. No debe ser fácil este momento de mantener software tan importante
En términos de satisfacción de los desarrolladores, eso produce, en ese orden, aumento, mantenimiento y disminución
La congelación de funcionalidades es una gran herramienta para cerrar bien una release, pero no es una buena herramienta para aliviar la presión de desarrolladores que trabajan marcando su propio rumbo