Un segundo NO-GO empuja el lanzamiento al 3 de noviembre, ocho llaves de certificados tan débiles como adivinar un dígito exponen a herramientas de código abierto, y el kernel 7.4 refuerza su blindaje de seguridad.
El comité de calidad del proyecto rechaza la última candidata por un fallo de certificados digitales de eMudhra y tres errores adicionales en el instalador y el cifrado de disco, según el calendario oficial de lanzamientos.
La reunión de go/no-go de Fedora 45, celebrada el 22 de octubre, terminó en un segundo NO-GO que posterga el lanzamiento al martes 3 de noviembre, según reportaron LinuxCompatible y PBXScience. El bloqueante principal es un problema de certificados: Fedora todavía acepta las llaves intermedias de la autoridad eMudhra que Mozilla documentó como trivialmente factorizables, por lo que el equipo necesita una versión actualizada del paquete ca-certificates antes de poder generar una nueva candidata. A esa lista se suman la imagen de Fedora Server 45 para AArch64, que supera el tamaño máximo permitido; una falla de activación automática de volúmenes LVM tras actualizar sistemas con cifrado LUKS; y que la aplicación Discover de KDE Plasma instala paquetes RPM desactualizados de Fedora 44. Es la segunda vez en ocho días que el proyecto declara un NO-GO: el primero, el 15 de octubre, se debió a que no había ninguna candidata disponible para que el equipo de calidad la probara. La candidata RC-1.2, publicada el 21 de octubre, había llegado con la mayoría de las pruebas en verde, según la cobertura previa de esta misma edición; el fallo de certificados cambió ese pronóstico en los dos días siguientes, cuando el caso eMudhra escaló a nivel de toda la industria. El proyecto fijó la próxima reunión de go/no-go para el jueves 29 de octubre a las 17:00 UTC. Para sostener la fecha del 3 de noviembre, el equipo debe incorporar el paquete ca-certificates corregido en una tercera candidata (RC-3) y el equipo de control de calidad debe verificar que los otros tres bloqueantes quedaron resueltos. Costa Rica no tiene industria de empaquetado de Fedora; las instituciones que dependen de RHEL o Fedora reciben esta versión con semanas de retraso respecto a Ubuntu, a través de los canales oficiales de Red Hat.
Mozilla documentó que ocho certificados intermedios emitidos por la autoridad india eMudhra usaban llaves privadas P-384 generadas con un error de abril de 2025 que reducía el espacio de valores posibles a apenas 256 combinaciones -una de ellas, literalmente, el número 4-, lo que permite reconstruirlas con cualquier certificado público asociado. Apple bloqueó esos certificados el 19 de octubre y Microsoft el 20 de octubre; Google anunció que retirará la raíz asociada del almacén de confianza de Chrome el 27 de octubre. eMudhra atribuyó el fallo a un error en el script usado para generar las llaves en 2025, según el comunicado que recoge Inc42. El caso expone una brecha entre navegadores y el resto del ecosistema de código abierto: mientras Apple, Google y Microsoft ya bloquearon las llaves comprometidas, TheNextWeb reportó que herramientas como curl, Python, Node.js, Go y Java, además de firmware de dispositivos IoT que ya no recibe actualizaciones, todavía confían en ellas porque dependen de almacenes de certificados propios o desactualizados. eMudhra sostiene, según el mismo comunicado, que no tiene evidencia de explotación activa de las llaves filtradas -una lectura que choca con la facilidad de adivinar un número de tres cifras que describe el reporte de Mozilla. Todavía no está claro qué distribuciones Linux actualizarán sus paquetes de certificados raíz y en qué plazo; Fedora ya identificó el problema como uno de los bloqueantes de su propio lanzamiento del 45. El impacto directo sobre Costa Rica es difuso: el país no tiene una autoridad certificadora conocida que dependa de eMudhra, y el riesgo se concentra en sitios o dispositivos extranjeros que todavía confíen en esas llaves.
El historial público del repositorio torvalds/linux en GitHub muestra que Linus Torvalds fusionó, el 22 de octubre, los árboles de sandboxing y control de acceso landlock, de políticas de integridad IPE, de llaves TPM mantenido por Jarkko Sakkinen y de criptografía de Herbert Xu, junto con los de cgroups, colas de trabajo y el planificador sched_ext. Al día siguiente, 23 de octubre, sumó los árboles de hardening, execve y seccomp de Kees Cook -los tres enfocados en reducir la superficie de ataque del núcleo- y el de almacenamiento de volcados de fallos pstore, además del primer bloque de cambios de redes para la versión 7.4. Esta tanda de seguridad llega después de que Phoronix reportara, el 20 de octubre, que el árbol de Rust para 7.4 -mantenido por Miguel Ojeda- ya suma unas 17.000 líneas nuevas de código, con un salto de ocho versiones en la librería vendorizada Zerocopy. La combinación de más Rust y más subsistemas de hardening en el mismo ciclo confirma que el proyecto sigue invirtiendo en blindaje de seguridad en paralelo a la migración de componentes críticos a un lenguaje con garantías de memoria más estrictas que C. Torvalds suele cerrar la ventana de fusión unas dos semanas después de abrirla, tras lo cual el kernel 7.4 entra en su ciclo de versiones candidatas semanales; no hay fecha fija de lanzamiento final. Costa Rica no participa en el desarrollo del kernel; el país recibe estos cambios de seguridad meses después, cuando distribuciones como Ubuntu, Fedora o RHEL los empaquetan.
cat /feed/omarchycontroldecalidad.md
Un mantenedor del proyecto confirmó el reporte el 22 de octubre y le pidió al autor del hallazgo que convierta su corrección propuesta en una solicitud de incorporación formal; a esta edición, nadie la había enviado.
> La incidencia #16244 del repositorio omacom/omarchy en GitHub -que describe cómo el comando omarchy language, ejecutado sin contraseña por una regla de sudoers, puede borrar todos los idiomas instalados cuando el disco está casi lleno- sigue abierta al cierre de esta edición. El único comentario registrado, del colaborador paulogeyer el 22 de octubre, confirma el comportamiento, propone limitar la reconstrucción de locales al idioma seleccionado con la herramienta localedef, y pregunta directamente al autor del reporte, mrjamesmyers, si piensa convertir su corrección en una solicitud de incorporación formal. Ninguna de las dos partes había actuado sobre esa pregunta a esta hora. La información sobre este reporte proviene únicamente del registro público de GitHub, sin cobertura de prensa especializada al cierre de esta edición.
> El fallo es uno de los más de diez que el repositorio acumuló desde el 21 de octubre, cuando la comunidad empezó a probar la versión candidata 4.5.0-rc1; la página oficial de lanzamientos del proyecto no registra ninguna versión posterior a esa candidata, por lo que ninguno de los reportes de esa tanda recibió todavía una corrección publicada. El patrón repite una tensión que esta edición viene documentando desde el lanzamiento de la 4.5.0-rc1: Omarchy sigue sumando patrocinio corporativo y un fondo de recompensas de US$100.000 en HackerOne mientras su propio backlog de errores crece más rápido que su capacidad de resolverlos.
> Ni la corrección de la incidencia #16244 ni una segunda candidata tienen fecha. Costa Rica no reporta instalaciones corporativas de Omarchy; la base de usuarios local se concentra en desarrolladores individuales que siguen el proyecto por su integración con herramientas de IA.
El 22 y el 23 de octubre combinaron el segundo NO-GO de Fedora 45 -empujado en parte por la crisis de certificados de eMudhra-, la fusión de varios subsistemas de seguridad en el kernel 7.4 y un backlog de errores de Omarchy que sigue sin resolverse. El caso eMudhra, además, expuso que buena parte del ecosistema de código abierto todavía confía en certificados que los navegadores ya bloquearon. Ningún hecho de esta edición tuvo epicentro en Costa Rica; el país sigue estos desarrollos a través de desarrolladores individuales y de las distribuciones que empaquetan estas actualizaciones semanas después.