Curl no aceptará informes de vulnerabilidades durante julio de 2026
Los mantenedores de curl planean pausar la aceptación de nuevos informes de vulnerabilidades durante julio de 2026 para poder tomarse unas “vacaciones de seguridad” sin interrupciones, mientras siguen dando soporte a los clientes con contrato de pago. Los comentaristas apoyan ampliamente la medida como una respuesta necesaria al agotamiento y al aumento de informes de baja calidad, a menudo generados por IA, pero también reaviva las preocupaciones sobre la dependencia global de infraestructuras de código abierto infradotadas y sobre quién debe pagar por una preparación de seguridad 24/7. El debate va desde si una divulgación pública inmediata durante ese mes sería responsable, hasta cómo deberían las empresas diseñar sus sistemas y sus prácticas organizativas —incluida la cultura de vacaciones— para que la seguridad no dependa de unos pocos voluntarios sobrecargados.
Reacción general
- Muchos comentaristas apoyan que los mantenedores de curl se tomen un mes libre de la gestión de vulnerabilidades, y lo califican de saludable, humano y largamente necesario.
- Algunos lo ven como un mensaje ingenioso que normaliza al mismo tiempo las vacaciones y promociona el soporte comercial.
- Unos pocos lo consideran “curioso” o arriesgado, pero aun así aceptan la necesidad de un descanso.
Soporte de pago y “arréglalo tú mismo”
- Se hace mucho hincapié en que curl es software libre sin garantía; quienes necesiten garantías deberían comprar un contrato de soporte.
- Varios comentarios subrayan que, al estar disponible el código fuente, las organizaciones pueden:
- Corregir los problemas por sí mismas.
- Mantener temporalmente un fork.
- Enviar los parches aguas arriba más adelante.
- Otros responden que el mantenimiento a largo plazo de forks y la integración en todo el ecosistema pueden ser costosos y poco prácticos.
Preocupaciones de seguridad y divulgación
- Algunos temen que los atacantes aprovechen el “mes de silencio” o se concentren en buscar zero-days entonces.
- Otros replican:
- Los atacantes serios no dependerían de todos modos del proceso de recepción del proyecto.
- Muchas vulnerabilidades de impacto ya son raras en proyectos maduros como curl.
- Debate sobre la “divulgación responsable”:
- Un lado: aun así hay que esperar (por ejemplo, 90 días es lo habitual), o al menos otro mes.
- El otro lado: si hay un fallo explotado activamente, la divulgación pública con un parche mínimo podría estar justificada.
- Varios señalan que solo existen normas comunitarias, no reglas estrictas.
Equilibrio entre vida laboral y personal, y cultura de vacaciones
- Largas subdiscusiones elogian la separación estricta entre trabajo y tiempo libre, incluyendo:
- Dejar los dispositivos de trabajo atrás o bloquear técnicamente el acceso.
- Managers que desaconsejan explícitamente o penalizan trabajar durante las vacaciones.
- Los comentaristas europeos describen normas de 4+ semanas de vacaciones, protecciones por enfermedad y respaldo legal y cultural para una desconexión real.
- Otros comparten contextos norteamericanos donde esos límites son más difíciles al inicio de la carrera, pero más posibles en niveles sénior.
Problemas sistémicos del OSS y de financiación
- Preocupación por el hecho de que infraestructuras críticas dependan de unas pocas personas infradotadas y sin respaldo.
- Algunos argumentan que los usuarios “consumen” OSS sin pagar, pero esperan SLAs de nivel empresarial.
- Debate sobre cómo los proyectos de moda (por ejemplo, herramientas de IA) atraen mucha más financiación que bibliotecas aburridas pero esenciales como curl.
Notas técnicas
- Breves menciones a herramientas de IA encontrando fallos en curl, a que las reescrituras en Rust son más difíciles de lo que parecen, y a enfoques alternativos como métodos formales o la compartimentación (por ejemplo, sandboxing, aislamiento al estilo Qubes).