Software moribundo: la evolución continua de relayd(8) y httpd(8)

 (rsadowski.de)
1 puntos por GN⁺ 2 시간 전 | 1 comentarios | Compartir por WhatsApp
  • El desarrollo de relayd(8) y httpd(8), que se había estancado por la menor atención de los desarrolladores existentes de OpenBSD, volvió a activarse gracias a la participación de contribuidores con necesidades reales de operación
  • Partiendo de la idea de que, precisamente en una época en que los LLM reemplazan el conocimiento de programación, hay que aprender C directamente y animarse a intentarlo, primero se modernizó el sistema artesanal de imsg de relayd(8)
  • Entre 2024 y 2026 se resolvieron la mayoría de los parches no incorporados de la lista de correo tech@ y los issues antiguos del mirror existente en GitHub, y también se prepararon un mirror en Git y un README para nuevos contribuidores
  • relayd(8) fortaleció una API imsg más segura, TLS y la seguridad del parsing de solicitudes, además de corregir choques durante recargas; httpd(8) agregó defensa contra request smuggling, headers definidos por el usuario y control de caché para archivos estáticos
  • La seguridad, estabilidad y extensibilidad de ambos daemons mejoró en conjunto, pero durante el trabajo también creció el backlog, por lo que siguen recibiendo ideas y feedback

El contexto detrás de revivir proyectos que habían perdido atención

  • Como se trató en Cambios principales de OpenBSD 7.8, el desarrollo de relayd(8) y httpd(8) estaba estancado
    • Varios contribuidores enviaron parches a la lista de correo tech@, pero casi ninguno fue incorporado al repositorio
    • La causa principal era que los desarrolladores existentes de OpenBSD ya no prestaban atención a ambos daemons
  • Junto con kirill@, se inició un desarrollo activo a partir de la experiencia de usar ambos daemons con regularidad y tratar casos de uso reales
    • La necesidad práctica de dar soporte a clientes de OpenBSD con configuraciones complejas de httpd(8) y relayd(8) también fue un motor directo

Por qué volver a C en la era de los LLM

  • El mayor detonante fue la aparición de los LLM
    • En el pasado escribía código C++ moderno de forma profesional, pero luego pasé a arquitectura de soluciones, ingeniería de plataformas y construcción de equipos, y casi dejé de escribir código real
    • Principalmente me quedé escribiendo YAML declarativo y leyendo y porteando código para ports(7) de OpenBSD
  • A diferencia de la afirmación de que “programar ya está resuelto”, consideré que en una época en la que el conocimiento se delega hacia afuera, es todavía más importante poseer ese conocimiento directamente
  • C++ y Rust sustituyen parte de las decisiones difíciles, pero C no lo hace; tomé eso como desafío y decidí contribuir a relayd(8) y httpd(8)

Contribuir sostenido por disciplina más que por motivación

  • La contribución open source puede terminar en frustración en cuestión de semanas, pero después de superar la etapa inicial dolorosa se alcanzó un estado en el que era posible trabajar de manera constante
  • Al principio, la lectura pasiva del codebase generó desaliento en varias partes
    • Las causas fueron la falta de comentarios, algunos diseños deficientes y código entrelazado de forma compleja; aún no está claro si eso es una característica del código en C o falta de experiencia personal
  • Tras conversar con los mantenedores de daemons de OpenBSD, se decidió modernizar el sistema artesanal de mensajes imsg
    • Primero se hizo foco en relayd(8) y luego se amplió el alcance a httpd(8)
    • El propio trabajo de modernización se usó como medio para entender el codebase

Limpieza de parches no incorporados e issues antiguos

  • Se revisaron los archivos de la lista de correo tech@ de 2024 a 2026 para recopilar parches e issues pendientes, y se considera que la mayoría ya fueron tratados
  • Ambos daemons fueron desarrollados originalmente por Reyk Floeter, ya retirado de OpenBSD
  • También se revisaron issues antiguos del mirror de relayd en GitHub que mantenía Reyk
    • Todos los issues están en condiciones de cerrarse o corregirse, y algunos ya no son válidos

Mirror en Git para nuevos contribuidores

  • Inspirándose en el mirror existente de GitHub, se creó un mirror separado para facilitar la entrada de contribuidores nuevos y jóvenes, y para crear puntos de contacto con comunidades fuera de las listas de correo de OpenBSD
  • Se usa el árbol CVS como mirror en Git, y el desarrollo primero se realiza en una instancia de Gothub y luego se sincroniza con el resto de los repositorios
  • Se aplicó el mismo enfoque a httpd(8) y se escribió un README.md detallado con la información necesaria

Modernización y calidad de código en relayd(8)

  • Se migró el sistema imsg a accesores más seguros como imsg_get_data, imsg_get_type e imsgbuf_get
  • Se agregó manejo de errores adecuado a todo el proceso de lectura de payloads imsg
  • Se estandarizaron logs y comentarios para mantener consistencia con bgpd
  • Se separó el procesamiento de la línea inicial HTTP en una función dedicada, mejorando la organización del código
  • Se aplicó el formato knfmt

Refuerzos de seguridad en relayd(8)

  • El conjunto de cifrados TLS por defecto se cambió de HIGH:!aNULL a secure
  • Se agregó soporte ECDSA al motor de separación de privilegios (privsep) de CA
  • Los headers Content-Length duplicados se rechazan con una respuesta HTTP 400
  • Según RFC 9112 5.2, no se permiten headers obs-fold para evitar diferencias entre parsers
  • Se verifica el ID de proceso y se restringe IMSG_CTL_PROCFD al proceso padre
  • Para borrar datos sensibles de contraseñas se usa explicit_bzero

Correcciones de bugs y mejoras de estabilidad en relayd(8)

  • Se corrigió una condición de carrera durante la recarga que provocaba choques
  • Se eliminaron varias fugas de memoria relacionadas con X509_dup, config_purge y tls_cfg
  • Se corrigieron verificaciones de NULL y de límites
  • Se agregó manejo de errores adecuado ante fallas de OpenSSL
  • En caso de fallo TLS, ahora se vacía la cola de errores de OpenSSL

Funciones agregadas a relayd(8)

  • Se soporta el método HTTP MKCALENDAR
  • Ahora se puede usar TLS en varios listeners
  • Se soportan varias direcciones resolubles por nombre
  • Se pueden configurar explícitamente las rutas de certificados, claves y OCSP staple
  • Se configura User-Agent en solicitudes HTTP de health check
  • Se manejan correctamente las respuestas HTTP sin cuerpo

Modernización y calidad de código en httpd(8)

  • Se migró proc.c a la nueva API imsg para mantener consistencia con relayd(8)
  • Se cambió el orden de los tokens para poder extender más fácilmente las opciones de configuración en el futuro
  • Se estandarizaron los logs para mantener consistencia con bgpd
  • Se eliminaron código duplicado y funciones vacías
  • Se aplicó el formato knfmt
  • Se separó el manejo de funcionalidades integradas en una función dedicada

Refuerzos de seguridad en httpd(8)

  • El conjunto de cifrados TLS por defecto se cambió de compat a secure
  • Para evitar ataques de request smuggling, se rechaza el framing de solicitudes CL.TE
  • Según RFC 9112 5.2, los headers obs-fold reciben una respuesta HTTP 400
  • Si los headers Content-Length y Transfer-Encoding existen al mismo tiempo, se trata como error
  • Para protección adicional, se realiza relink aleatorio al arrancar
  • Se verifica el ID de proceso y se restringe IMSG_CTL_PROCFD al proceso padre
  • Se agregó la opción no banner para ocultar la identificación del servidor en las respuestas

Correcciones de bugs y mejoras de estabilidad en httpd(8)

  • Se corrigió el manejo de suffix range en solicitudes HTTP
  • Se arregló server_http_time() para que emita correctamente la hora GMT
  • Se verifica el error de timegm(3) según la especificación del manual
  • Se solucionó un problema de uploads que usan chunked transfer-encoding
  • Se corrigió que fcgiparams de location no se enviara dos veces
  • Se agregó manejo de errores adecuado a dispatch_parent
  • Se cambió el vaciado de respuestas abortadas para que se haga correctamente mediante bufferevent
  • Se eliminó una escritura innecesaria encontrada por scan-build
  • Se valida return_uri_len antes de copiar datos

Nuevas funciones y trabajo pendiente en httpd(8)

  • Se soportan headers HTTP definidos por el usuario
  • Para una mejor herencia de configuración, location hereda gzip-static
  • Se ampliaron los flags del servidor a enteros de 64 bits para aceptar más opciones de flags
  • Se agregó control de caché para archivos estáticos
  • A medida que avanzó el trabajo, el backlog creció, y siguen recibiendo ideas y feedback para el desarrollo futuro

Lecturas relacionadas

1 comentarios

 
GN⁺ 2 시간 전
Comentarios en Lobste.rs

  • Se agradece el soporte para encabezados HTTP personalizados. Antes, al no existir esta función, no se podía usar httpd ni siquiera para casos simples; qué bueno que ahora ya esté soportada.

  • El desarrollo de relayd(8) y httpd(8) estaba estancado, y varios colaboradores habían enviado parches a la lista de correo tech@, pero casi no se incorporaban al repositorio. Al parecer, la razón principal era que los desarrolladores actuales de OpenBSD ya no estaban interesados en estos demonios, así que se agradece que alguien haya tomado el relevo del mantenimiento.

  • Uso ambos programas con regularidad y me alegra que vuelvan a estar bien mantenidos. No tenía idea de que el desarrollo estuviera estancado.
    Parece que, gracias a una estructura de software simple, pudieron reactivar el desarrollo e incorporar tantas funciones y correcciones sin necesidad de un equipo grande.

  • Durante un tiempo me confundían los números después de los nombres del software, hasta que entendí que son los números de sección del manual.
    1 significa programas ejecutables y comandos de shell; 2, llamadas al sistema; 3, llamadas de biblioteca; 4, archivos especiales; 5, formatos y convenciones de archivos; 6, juegos; 7, miscelánea; 8, comandos de administración del sistema; y el 9 no estándar, rutinas del kernel.

    • Ejecuta man 1 man o, en corto, man man para consultar man(1). En particular, son útiles las varias páginas intro que aparecen en SEE ALSO.

  • Me pregunto si estas mejoras se incluirán en OpenBSD 8.0.

  • Me pregunto si el enlace estaba pensado para ser legible. En Firefox para Android se ve así:
    https://imgur.com/a/oTimS9R