# Fedora 45 se retrasa por un certificado que Linux ya sufría > Fedora 45 pierde su segunda fecha y apunta al 3 de noviembre. Un certificado de eMudhra sin retirar, LVM y Stratis están entre los bloqueantes de la salida. > Por José Maldonado · Tecnología · 2026-10-30 Fedora 45 no salió el 15 de octubre y tampoco el 22, como se había reprogramado. En la reunión de go y no-go de ese segundo día se declaró un nuevo NO-GO y la fecha objetivo pasó al martes 3 de noviembre, según confirmó el equipo de release. La responsable del ciclo, Aoife Moloney, señaló como bloqueante principal [un certificado de eMudhra](https://www.linuxcompatible.org/story/fedora-linux-45-final-nogo-release-delayed-to-november-3-2026/) que sigue dentro del almacén de confianza del sistema, y a ese se le suman tres fallos más: la autodesactivación de LVM, un Plasma Discover que sirve paquetes RPM desactualizados y un arranque roto en grupos cifrados de Stratis. El primero de esos bloqueantes tiene una historia detrás que este medio ha seguido de cerca. La autoridad india eMudhra emitió certificados intermedios con claves privadas ridículamente débiles, los navegadores los bloquearon en cuestión de horas y la empresa anunció su retirada del negocio del SSL global. Una distribución no puede publicar una imagen con esa autoridad dentro de su lista de confianza, así que el problema dejó de ser una noticia de seguridad y se convirtió en un freno de calendario para millones de instalaciones. Es la segunda vez consecutiva que Fedora se queda sin fecha. La anterior, el 15 de octubre, no fue por un fallo de software sino por logística: no hubo medios de instalación candidatos publicados a tiempo para la reunión. Dos NO-GO seguidos con causas distintas dibujan un ciclo con más presión de la habitual, y explican por qué la comunidad ha preferido fijar el 3 de noviembre en lugar de arriesgar un tercer intento fallido. ## Un certificado que no debería estar ahí La cadena de confianza de un sistema operativo es una lista de autoridades en las que el sistema cree por defecto. Si una de ellas firma con claves que se pueden recalcular, cualquiera puede emitir un certificado válido para cualquier dominio y el modelo entero se cae. Retirar una autoridad de esa lista no es tan simple como borrar una línea. Hay que comprobar qué paquetes dependen de ella, si alguna cadena la necesita para funcionar y cómo afecta el cambio a los sistemas ya instalados. Lo contamos al analizar el [golpe a los certificados TLS de eMudhra](https://observatorioblockchain.com/ciberseguridad/certificados-tls-emudhra-comprometidos/), donde las claves se podían factorizar. En el caso de una distribución, el problema se multiplica porque la decisión afecta a la imagen de instalación, a los sistemas ya desplegados y a los contenedores que se construyan a partir de ella. Cocinar la imagen con la autoridad dentro sería publicar un producto que nace con una brecha conocida. ## Los otros tres bloqueantes LVM, el gestor de volúmenes lógicos, aparece con un problema de autodesactivación que afecta a la disponibilidad de volúmenes en el arranque. Un fallo ahí puede dejar un equipo sin acceso a su propio disco, que es el tipo de error que no se puede tolerar en una versión estable. El segundo es de distribución de software. Plasma Discover, la tienda de aplicaciones del escritorio KDE, estaba sirviendo paquetes RPM desactualizados, y en una release eso significa que el usuario puede instalar una versión anterior a la que cree. La ironía es fina: el mecanismo pensado para mantener el sistema al día entregaba lo viejo. El tercero afecta a Stratis, el gestor de almacenamiento con cifrado, y se manifiesta como un fallo de arranque en grupos cifrados. Quien haya configurado el disco con cifrado y no pueda entrar después de una actualización es el escenario que ninguna distribución quiere protagonizar el día del lanzamiento. Bloqueante Qué rompe Alcance Certificado de eMudhra Cadena de confianza del sistema Imagen y sistemas instalados Autodesactivación de LVM Volúmenes lógicos en el arranque Equipos con LVM Plasma Discover Entrega de RPM desactualizados Escritorio KDE Stratis cifrado Arranque en grupos cifrados Instalaciones con Stratis ## Lo que un retraso le cuesta a una distro Cada semana de retraso tiene un precio que no aparece en el comunicado. Los probadores que se habían organizado para la fecha original reprograman su tiempo. Los mantenedores de paquetes ven cómo su trabajo se acumula detrás de una release que no llega. Y los usuarios que esperaban la nueva versión empiezan a mirar alternativas, aunque sea para el portátil de pruebas. También hay un coste de credibilidad cuando la causa es un certificado comprometido. No es culpa de Fedora que eMudhra emitiera claves débiles, pero sí es su responsabilidad que la lista de confianza esté limpia antes de publicar. La decisión de retrasar es la correcta y, a la vez, la que más incomoda. El contraste con otras distribuciones sirve para situar el caso. Hay proyectos que habrían publicado con la nota de que el certificado se retiraría en la siguiente actualización. Fedora ha elegido lo contrario, y ese criterio explica por qué esta distro se usa en entornos donde la predictibilidad importa más que la novedad. El proceso de go y no-go es una reunión pública en la que se repasa la lista de bloqueantes y se decide si la imagen cumple los criterios. Cada bloqueante tiene un responsable y una condición de cierre, y ahí no vale el criterio de urgencia comercial: si el fallo impide arrancar o rompe una cadena de confianza, la release no sale. Ese rigor tiene un efecto secundario poco visible. Las derivadas de Fedora, desde las variantes atómicas hasta las imágenes para servidores, heredan la fecha, así que un NO-GO mueve el calendario de media docena de productos que ni siquiera participan en la reunión. Quien quiera entender por qué Fedora tiene ese papel puede empezar por el [conocer sobre Fedora y su relación con Linus Torvalds](https://observatorioblockchain.com/tecnologia/fedora-linux-explicado-distro-linus-torvalds/), donde se cuenta qué la distingue de otras opciones y por qué se ha ganado la confianza de quien desarrolla software. ## ¿Qué puede hacer el usuario mientras espera? Si tienes Fedora 44 funcionando, la recomendación sensata es no tocar nada y esperar al 3 de noviembre. Actualizar a una beta para adelantar dos semanas es la clase de decisión que se paga en horas de soporte, sobre todo si el equipo se usa para trabajar. Si lo que te interesa es el certificado, no hace falta esperar a la release. Comprobar el almacén de confianza del sistema y verificar si alguna cadena depende de eMudhra es una tarea de cinco minutos que conviene hacer igualmente, porque afecta a cualquier distribución y a cualquier servidor con TLS. El tercer consejo tiene que ver con el arranque cifrado. Antes de actualizar, comprueba que tienes acceso a la contraseña de recuperación y que sabes cómo montar el volumen desde un medio externo. Es una precaución aburrida que, cuando hace falta, decide si pierdes un día o pierdes los datos. ## La fecha del 3 de noviembre y lo que viene después El 3 de noviembre es un martes, y el equipo ha dejado margen para una última semana de pruebas. Si los cuatro bloqueantes se cierran antes, la release saldrá; si alguno se resiste, habrá una tercera fecha y nadie debería sorprenderse. Mientras tanto, el episodio deja una lección que trasciende la distro. La seguridad de una cadena de software depende de piezas que casi nunca se miran: una autoridad de certificación, un gestor de volúmenes, una tienda de aplicaciones. Cuando una de esas piezas falla, la release no se retrasa por capricho, sino porque el producto que iba a salir no era el que se quería firmar.