Freenginx: el desarrollador principal de Nginx anuncia un fork
Un desarrollador principal de Nginx ha creado un fork llamado Freenginx tras chocar con el propietario corporativo F5 por la política de seguridad, en particular por la decisión de asignar CVE a una vulnerabilidad en el código experimental HTTP/3 de Nginx. Los comentaristas ven la ruptura como un reflejo de tensiones más profundas entre los mantenedores voluntarios y el control corporativo de una infraestructura crítica de código abierto, lo que plantea preguntas sobre las prácticas de divulgación, las marcas registradas y la gobernanza del proyecto. Muchos ahora se preguntan si seguir con Nginx, pasar al nuevo fork o cambiar a alternativas como Caddy, HAProxy o Angie.
Motivo del fork y disputa de gobernanza
- El fork (“Freenginx”) se presenta como una respuesta a que la gestión corporativa no técnica (F5) anulara la política de seguridad de Nginx de larga data y las preferencias de los desarrolladores.
- El desencadenante inmediato parece ser que F5 publicara avisos de seguridad y CVE por un error en el código experimental de HTTP/3/QUIC, en contra de los deseos del mantenedor principal, que consideraba que debía tratarse como un error normal según la política existente.
- Algunos comentaristas lo ven como un “rage-fork”; otros lo consideran una reacción legítima a la pérdida de control sobre un proyecto de código abierto y a un conflicto que venía gestándose desde hacía tiempo, no solo a un único CVE.
Debate sobre CVE y política de seguridad
- El personal de seguridad de F5 sostiene que siguió las reglas de CVE, que las funciones experimentales pero ya distribuidas están dentro del alcance, que HTTP/3 ya se usa en producción y que los usuarios deben ser informados.
- La postura contraria: asignar CVE a funciones experimentales y no predeterminadas (o a errores solo de denegación de servicio) añade ruido, fomenta la “gamificación” de los CVE y carga a los downstream con trabajo de “seguridad” de poco valor.
- Hay una crítica más amplia de que los recuentos de CVE se usan como KPI y de que los procesos de seguridad pueden volverse autoritarios y politizados.
Forks existentes, licencia y nombre
- Ya existe otro fork de nginx, Angie, gestionado por una empresa con ánimo de lucro, con CLA y una versión “pro”; algunos desconfían de este modelo como un posible cambio futuro de licencia.
- Freenginx mantiene la licencia BSD original de 2 cláusulas y usa Mercurial, alojado fuera de GitHub.
- Varias personas señalan que F5 posee la marca registrada de nginx y esperan conflictos por el dominio y el nombre; abundan las sugerencias de cambiar de marca. Otros argumentan que la aplicación fuera de las fronteras es poco probable, pero podría afectar al dominio .org.
Alternativas y conversación sobre migración
- Muchos hablan de migrar o de haber migrado ya a HAProxy, Caddy, Traefik, lighttpd o incluso Apache httpd, según necesidades como servir archivos estáticos, simplicidad o balanceo de carga avanzado.
- Caddy recibe elogios repetidos por su TLS automático y su configuración más simple, pero su ecosistema sufre de “bloqueo por documentación” en ejemplos de nginx.
Preocupaciones técnicas y del ecosistema
- Diversas quejas técnicas sobre nginx: conexiones persistentes HTTP/1.1 que se caen al recargar, problemas históricos de request smuggling (reportados como corregidos y reforzados), falta de soporte de HTTP/2 en upstream y algunos valores predeterminados “heredados”.
- Otros defienden la estabilidad, el rendimiento y el conjunto de funciones “suficientemente bueno” de nginx; para muchos casos de uso, incluso un nginx de hace años sería suficiente.
- Varios comentaristas se preocupan por que infraestructura crítica dependa de 1 o 2 desarrolladores principales, pero señalan que el código abierto y los forks ofrecen un camino a seguir, aunque con desafíos de financiación y sostenibilidad.