HardenedBSD mete -fbounds-safety en userland y vuelve a sincronizar con GitHub
El informe de estado de agosto y septiembre adelanta la release trimestral, migra dos VMs a jails y detalla cómo le afecta la vulnerabilidad de Radicle del 23 de septiembre.
HardenedBSD ha publicado su informe de estado de agosto y septiembre, adelantado porque la semana del 28 toca ingeniería de la release trimestral. En src, el proyecto ha metido la fontanería de -fbounds-safety en userland (desactivada por defecto) y ha endurecido la configuración de SSH desactivando compresión y keepalives TCP. También ha vuelto a sincronizar sus repositorios src y ports con GitHub.
-fbounds-safety, disponible pero apagado
El indicador real se escribe -Xclang -fexperimental-bounds-safety y se activa en el árbol con MK_BOUNDS_SAFETY, que viene deshabilitada. No se usa en ninguna parte de la base del sistema operativo. Lo que ha hecho el proyecto es tender la tubería para que quien construya sobre HardenedBSD decida por su cuenta si adopta la característica. De momento solo está integrada en userland; cuando el equipo de clang/llvm la considere lista para producción, se duplicará la lógica para kernel y módulos. Shawn Webb la compara con Capsicum: requiere integración directa en el código del proyecto, un enfoque que a él le parece pesado, pero que deja la decisión en manos de cada cual.
El resto de cambios en src es variado: bsdinstall disuade del uso de pkgbase, se actualizan /etc/os-release y /var/run/os-release, se activa -ftrivial-var-auto-init=zero para video(4), se documenta el rechazo a obras generadas por IA o LLM y se corrigen referencias rotas en la página de manual hardening(4) y enlaces en motd.template. En ports, se arregla una dependencia rota de math/libformfactor. Webb adelanta además que piensa hacer cherry-pick de varios commits que, según él, huelen a seguridad desde la rama main de FreeBSD a su rama 15-stable, y no descarta que aparezca un aviso de seguridad o una errata de FreeBSD en las próximas semanas.
Jails, GitHub y el susto de Radicle
En infraestructura, dos entornos han pasado de VM a jail: rad.hardenedbsd.org y ngx-01. Las primeras 48 horas dieron problemas y, aunque la cosa ha mejorado, quedan incidencias latentes. El tráfico sigue muy por encima de lo normal, así que el throttling puede obligar a refrescar la interfaz web del nodo Radicle. El siguiente en migrar será el rsync, después de que terminen los builds trimestrales y se sincronicen con los espejos, y luego tocará modernizar los endpoints de Tor Onion Service. La auto-sincronización ahora empuja a varios remotos y GitHub vuelve a estar soportado para src y ports, con hasta seis horas de desfase porque el proceso corre cada seis horas. Los proyectos auxiliares (hbsdmon, libhijack, vm-bhyve-hbsd) no se reflejan allí. El plan a largo plazo es un daemon de orquestación en Rust que hable directamente con el nodo Radicle por su control socket, algo que Webb describe como un CI/CD lite.
Sobre la vulnerabilidad de Radicle revelada el 23 de septiembre, Webb explica que un nodo malicioso puede forzar a otro a exponer repositorios privados, porque solo el handshake inicial va cifrado y el resto de la conversación viaja en claro. HardenedBSD no usa repositorios privados en Radicle y ofrece un endpoint Tor Onion Service, así que el problema de exposición no le alcanza; para quien quiera protegerse también del análisis de tráfico, recomienda Tor. Mantiene que Radicle sigue siendo la elección correcta, pero avisa de que su migración a iroh impactará al proyecto y a sus usuarios. Y añade una crítica sin adornos: un tcpdump a tiempo habría detectado esto.
