Thunderbird 151 llega cuatro semanas después de la versión anterior, y representa una de las actualizaciones más importantes de Mozilla en los últimos meses. Enfocada especialmente en la autenticación moderna y en optimizar la experiencia de configuración automática de cuentas, esta versión introduce mejoras sustanciales en seguridad, compatibilidad con servicios empresariales y una gestión más fluida del inicio de sesión mediante OAuth.

La propuesta de Thunderbird 151 apuesta por simplificar la vida del usuario, avanzando hacia una automatización total del proceso de configuración de cuentas de correo. Esta meta reduce errores durante la conexión inicial y mejora la compatibilidad con servicios como Microsoft Exchange y otros proveedores que dependen de autenticación moderna. Paralelamente, se han corregido numerosos fallos relacionados con la estabilidad, la búsqueda de mensajes y la gestión de adjuntos, consolidando esta actualización como una de las más completas hasta la fecha.

Thunderbird 151 y la nueva autenticación OAuth con configuración automática de cuentas

Uno de los cambios más relevantes es la incorporación del inicio de sesión OAuth para cuentas que lo soportan, junto con la configuración automática de cuentas. Esto permite a los usuarios introducir credenciales sin necesidad de configurar manualmente los parámetros de IMAP, SMTP o Exchange en muchos casos, simplificando así procesos complejos para usuarios finales.

Además, se añade la posibilidad de modificar los parámetros del proveedor OAuth en cuentas EWS, una característica especialmente útil en entornos corporativos donde las políticas de autenticación pueden variar. Esta mejora responde a la evolución de los servicios de correo modernos, donde las contraseñas tradicionales están siendo sustituidas por sistemas de autenticación basados en tokens más seguros.

Otra mejora destacada es la corrección de problemas en el asistente de configuración de cuentas, que anteriormente podía fallar al detectar ciertos parámetros del servidor. Con esta versión, el proceso es más estable y reduce significativamente los errores iniciales de conexión.

En términos de estabilidad, Thunderbird 151 soluciona bloqueos al procesar mensajes, errores al arrancar, y problemas con el filtrado de spam y la sincronización de carpetas IMAP. También se han reforzado la interfaz de tareas, la búsqueda dentro de mensajes y la gestión de adjuntos, convirtiendo al cliente en una herramienta más sólida tanto para usuarios domésticos como para profesionales.

En conjunto, esta actualización refuerza la estrategia de Mozilla de modernizar Thunderbird sin perder su esencia de cliente de correo abierto, potente y multiplataforma, adaptándolo a los estándares actuales de seguridad y autenticación en la nube.

from Linux Adictos https://ift.tt/seTAmN8
via IFTTT

Hace un par de meses desde que empezó a sonar un rumor que no gustó demasiado en la comunidad gamer: Sony se estaba planteando dejar de llevar sus títulos al PC. El principal motivo parecía estar en las bajas ventas en ordenadores e ingresos por debajo de lo esperado, lo que les llevaría a pensar que no merece la pena gastar tiempo y dinero. Ahora, el CEO del estudio lo ha confirmado.

Yo pondría «confirmado», porque nunca se sabe. Pero, según Jason Schreier de Bloomberg, que lo ha publicado en Bluesky, Hermen Hulst, CEO del negocio del estudio de PlayStation, ha dicho que «los juegos narrativos de un jugador de la compañía serán ahora exclusiva de PlayStation». Con este movimiento buscarían fortalecerse como plataforma, acercándose al modelo de negocio de Nintendo, compañía que tiene fieles e incluso fans.

El cambio de idea en Sony

Sony ha llevado muchos juegos de PlayStation al PC. No ha vendido lo que esperaba, y además, ha recibido críticas siempre que ha pedido que se use una cuenta de PlayStation Network. Por ejemplo, en Steam tenemos títulos como Horizon Zero Dawn (mi favorito), los God of War de la saga nórdica, The Last of Us, Stellar Blade y muchos más, y casi siempre con unas ventas discretas.

Estrategia de plataforma aparte, dejar de llevar sus juegos al PC parece lo más lógico: si no amortizan el esfuerzo y encima reciben críticas, poco más hay que hablar. Pero quizá hay algo que no han tenido en cuenta.

Dicho sea de paso, se seguirían llevando los títulos multijugador al PC.

No venden tanto en PC… ¿quizá por cuándo llegan?

Cuando uno se mueve en redes sociales o lee un poco por Internet, ve que los jugadores de PC se quejan de cuándo han lanzado los títulos en ordenadores. Por poner algunos ejemplos, Horizon Forbidden West se lanzó en 2022, y a Steam llegó dos años más tarde. Pero es que God of War, el primero de la saga nórdica, es un título de 2018 que llegó a Windows en 2022.

Muchos jugadores tienen una manera de ser que les hace preferir lo más nuevo y que no les guste tener un trato de segunda. El comentario más generalizado es que Sony ha llevado sus títulos al PC varios años después de su lanzamiento, y las esperas son dolorosas. Al final parece ser el desgaste (o despecho) el que hace que los títulos no interesen años después de su lanzamiento.

XBOX, la Steam Machine y las consolas

En mi opinión, Sony se equivoca. Sus plazos no han sido los correctos. Parece que se han fijado en Nintendo, pero no es el momento de hacerse fuerte como plataforma. Ya no. Nintendo es una compañía que existe desde el siglo XIX, aunque lo que nos interesa más tuvo lugar en los años ’70 del XX. Fue cuando empezaron con los juguetes electrónicos, y ya en los 80 nos entregaron la NES (Nintendo Entertainment System).

Desde el principio, hace ya más de 40 años, Nintendo ha buscado ser una plataforma, y lo ha conseguido. Sus productos más recientes, como la Switch 2, son un éxito, en parte por la legión de fans que han conseguido a lo largo de los años. Sony empezó con las consolas en los ’90, y no han tenido tan claro su camino. Han tenido que pelearse con Microsoft, y no tienen la imagen de marca que tiene Nintendo.

XBOX (ahora en mayúsculas, sí) está pensando en una línea totalmente opuesta: su próxima consola va a ser un PC casi al 100%, y todo lo de XBOX estará disponible en PC y viceversa. También llegará la Steam Machine, que es un ordenador que se lanzará con Linux, pero no nos obliga a quedarnos ahí (se podrá instalar Windows).

Sony no es ni será Nintendo

Sony va a intentar conseguir tener esa legión de fans que tiene Nintendo, y habrá que ver si lo consigue. Sinceramente, al leer las palabras del CEO de la plataforma de PlayStation, lo primero que he pensado ha sido en si yo sería capaz de tener un PC y una PlayStation, para llegar a la conclusión de que no. Luego he pensado en cómo será la emulación de PS6 en el futuro, y finalmente en que espero que «caigan del burro» y vuelvan a llevar sus títulos al ordenador, pero ahora a tiempo.

from Linux Adictos https://ift.tt/yOGzQbV
via IFTTT

La comunidad del kernel de Linux vive un momento de revisión profunda de cómo se reportan y gestionan las vulnerabilidades, en buena parte por el impacto directo de las herramientas de IA en la auditoría de código. La adopción masiva de estos sistemas ha disparado el volumen de avisos de seguridad, pero también ha destapado un problema serio de duplicación, ruido y carga extra para los mantenedores.

Linus Torvalds, figura central del proyecto, ha llegado a calificar (en las notas de lanzamiento de Linux 7.1-rc4) la lista privada de seguridad del kernel como “casi completamente inmanejable” por la avalancha de reportes apoyados en IA, muchos de ellos repetidos o mal clasificados. Ante este escenario, el proyecto ha respondido con nueva documentación integrada en Linux 7.1 que redefine qué se considera fallo de seguridad real y cómo deben gestionarse los informes generados con ayuda de modelos de IA.

Una lista de seguridad desbordada por informes duplicados

En sus comunicaciones recientes sobre el desarrollo de Linux 7.1, Torvalds ha advertido de que la lista de correo dedicada a vulnerabilidades se ha convertido en un cuello de botella donde se mezclan avisos importantes con una multitud de informes redundantes. El problema no es solo la cantidad, sino que distintas personas, usando las mismas herramientas automáticas, acaban enviando exactamente los mismos hallazgos.

Según explicó, los desarrolladores pierden mucho tiempo reenviando mensajes a quienes realmente deberían recibirlos o aclarando que el fallo ya fue corregido días o semanas atrás en ramas del kernel. Esta situación, comparada por algunos con una “inundación” de correos, obliga a dedicar recursos a aclarar duplicidades en lugar de centrarse en vulnerabilidades nuevas y graves.

Willy Tarreau, veterano mantenedor estable del kernel y conocido por su trabajo en HAProxy, ha aportado cifras ilustrativas: hace apenas un par de años la lista privada recibía entre dos y tres reportes por semana, mientras que ahora se manejan entre cinco y diez reportes diarios. Muchos provienen de análisis asistidos por IA que, aunque en ocasiones señalan problemas reales, llegan en formatos poco prácticos y sin aportar información adicional relevante.

Torvalds no carga contra la IA, sino contra el mal uso

Aunque pueda parecer lo contrario, Torvalds ha dejado claro que no se opone al uso de la inteligencia artificial como herramienta de desarrollo y auditoría. Él mismo reconoce emplear este tipo de sistemas en su trabajo, pero insiste en que deben utilizarse de forma responsable y con criterio.

En sus mensajes a la comunidad ha remarcado que las herramientas de IA “son geniales” cuando realmente ayudan, pero se convierten en un problema cuando generan “dolor innecesario y trabajo ficticio inútil”. En otras palabras, el simple hecho de que un modelo automático señale una posible vulnerabilidad no justifica inundar los canales de seguridad con informes mal verificados o sin contexto técnico.

Torvalds insiste en que quien use IA para encontrar fallos no debería limitarse a reenviar un resultado bruto, sino leer la documentación del kernel, comprender el modelo de amenazas y, siempre que sea posible, aportar un parche o al menos una explicación sólida del impacto. El objetivo es que los humanos añadan valor sobre el trabajo automatizado, en lugar de actuar como meros intermediarios entre la herramienta y la lista de correo.

Nuevas reglas en Linux 7.1: qué es vulnerabilidad y qué no

En respuesta a esta situación, el proyecto del kernel ha incorporado en Linux 7.1 una documentación más precisa sobre qué fallos deben tratarse como vulnerabilidades de seguridad y cuáles son simples bugs a gestionar por los cauces habituales. El texto, redactado por Willy Tarreau, ya forma parte del árbol Git del kernel y está disponible antes de la publicación de Linux 7.1-rc4.

La guía parte de una idea sencilla: la mayoría de los errores no deberían canalizarse por la lista privada de seguridad, sino tratarse abiertamente en las listas públicas de desarrollo. Al discutir los problemas en público se suman más revisores, se cubren más escenarios de uso y se alcanzan soluciones, en general, de mayor calidad.

El documento recuerda que Linux ya contaba con un modelo de amenazas claramente definido, que ahora sirve como referencia principal a la hora de decidir si un fallo debe gestionarse en privado. Se considera vulnerabilidad de seguridad aquella que permite a un atacante obtener capacidades que no debería tener en un sistema de producción correctamente configurado, que resulte razonablemente explotable y que represente una amenaza real para un volumen importante de usuarios.

En la práctica, se invita a quienes descubran problemas a preguntarse si el error realmente cruza un límite de confianza en un entorno típico. Si la respuesta es negativa, el camino recomendado pasa por las listas públicas (como la LKML y las listas específicas de cada subsistema), no por el canal reservado de seguridad. Aun así, la guía concede un margen prudente: ante la duda, se prefiere revisar en privado un informe dudoso a dejar escapar una vulnerabilidad auténtica.

Otro punto clave del texto es que enviar bugs ordinarios a la lista privada no hace que se solucionen antes; al contrario, consume el tiempo de clasificación que el equipo de seguridad necesita para priorizar fallos realmente críticos. Saturar ese canal con problemas menores significa, a la larga, empeorar la protección general de los sistemas que dependen de Linux, incluidos servidores, infraestructuras cloud y dispositivos industriales.

El modelo de amenazas: separación de privilegios y casos excluidos

La nueva documentación actualiza y detalla el modelo de amenazas del kernel, que enumera las garantías cuya ruptura sí se considera un problema de seguridad digno de atención prioritaria. Entre ellas están la separación entre espacio de usuario y kernel, el aislamiento de memoria entre procesos, las restricciones de ptrace, el aislamiento de mecanismos de IPC y red, y las protecciones asociadas a capacidades sensibles como CAP_SYS_ADMIN, CAP_NET_ADMIN o CAP_SYS_PTRACE.

Se presta especial atención a los espacios de nombres de usuario (user namespaces), donde configuraciones como CONFIG_USER_NS permiten a usuarios sin privilegios crear entornos aislados. La expectativa del proyecto es que esas instancias no puedan comprometer el sistema global, de modo que cualquier desborde de ese aislamiento adquiere relevancia de seguridad.

También se analizan interfaces de depuración como /proc/kmsg, perf o debugfs, recordando que el acceso a información delicada a través de estos mecanismos debe estar bloqueado a menos que el administrador lo autorice expresamente. En caso contrario, se corre el riesgo de filtrar datos que puedan utilizarse para afinar ataques o escalar privilegios.

Junto a esta definición de garantías, la guía deja claro qué tipo de problemas no deben etiquetarse automáticamente como vulnerabilidades. Se incluyen en esa categoría errores en ramas obsoletas del kernel, opciones de compilación inseguras elegidas por el propio administrador, permisos incorrectos en sysctl o en sistemas de archivos, funciones reservadas para depuración (LOCKDEP, KASAN, FAULT_INJECTION) y código experimental en áreas de staging.

Tampoco se consideran vulnerabilidades, por defecto, los fallos que exigen privilegios exagerados, escenarios de laboratorio muy alejados del uso real, hardware manipulado, un número inasumible de intentos o configuraciones que ningún administrador sensato aplicaría en producción. Igualmente, las filtraciones de información sin exploit claro y ciertos problemas en imágenes de sistemas de archivos, que normalmente gestionan herramientas como fsck, quedan fuera del ámbito principal del canal de seguridad.

Hallazgos asistidos por IA: de lo privado a lo público

Uno de los cambios más llamativos de la actualización es la postura frente a los fallos localizados con ayuda de IA. La documentación sostiene que los bugs detectados mediante análisis automatizados deben tratarse como esencialmente públicos, aunque el primer envío se haga por correo privado.

La razón es puramente práctica: la experiencia reciente del equipo de seguridad muestra que esos fallos suelen aparecer de forma simultánea en manos de varios investigadores que experimentan con herramientas similares. Es habitual que en cuestión de horas lleguen varios correos describiendo la misma condición, con ligeras variaciones de formato, lo que convierte en irreal cualquier expectativa de confidencialidad prolongada.

Esta nueva realidad lleva a Torvalds a defender que no tiene sentido tratar estos hallazgos como secretos que deban esconderse hasta que exista un parche. Si una IA común es capaz de encontrarlos, es razonable asumir que otros actores, incluidos posibles atacantes, pueden llegar al mismo resultado. Etiquetarlos como vulnerabilidades reservadas solo añade trabajo extra y complica la coordinación.

Eso no significa que se recomiende publicar sin filtro todos los detalles técnicos. La guía pide que, en los casos detectados con IA, no se comparta de inmediato un reproductor funcional del fallo (la secuencia exacta de pasos o código que dispara el error). Lo apropiado es indicar que ese material existe y dejar que los mantenedores lo pidan de forma privada si lo consideran necesario para validar la corrección.

Con este enfoque, el proyecto intenta conjugar dos intereses: por un lado, evitar la saturación de la lista privada con hallazgos que otros ya conocen; por otro, no ofrecer a cualquiera una “receta” de explotación antes de disponer de mitigaciones. El reproductor se reconoce como una herramienta valiosa tanto para la depuración como para la evaluación de impacto, pero también como un punto delicado si se difunde sin controles mínimos.

Exigencias de calidad para los reportes generados con IA

La nueva documentación dedica un apartado entero a cómo deben redactarse los informes apoyados en inteligencia artificial. La queja recurrente de los mantenedores es que muchos de esos reportes llegan excesivamente inflados, con explicaciones redundantes y poco foco en los datos esenciales, lo que complica su lectura y clasificación.

En primer lugar, se pide que los informes sean breves, claros y en texto plano. El equipo desalienta el uso de formatos como Markdown, adornos o estructuras complejas que luego no sobreviven bien a las respuestas encadenadas en las listas de correo. La idea es que, al reenviar o citar el mensaje, no se pierda información ni se convierta el texto en un bloque ilegible.

En cuanto al contenido, se recomienda comenzar con un resumen simple que indique el archivo o subsistema afectado, las versiones impactadas y el efecto observable del bug. A partir de ahí se pueden añadir detalles, pero siempre con la intención de facilitar una lectura rápida que permita decidir si el fallo es prioritario o entra en la categoría de problemas menores.

Otro aspecto importante es la forma de describir el impacto. Los responsables del kernel advierten de que muchos informes generados con IA tienden a exagerar las consecuencias teóricas, encadenando escenarios hipotéticos que no respetan el modelo de amenazas real del proyecto. En lugar de construir historias de ataques complejos, se pide ceñirse a hechos verificables, como explicar de manera concreta qué capacidades adicionales podría obtener un usuario en un sistema configurado de forma estándar.

La guía llega a sugerir que, cuando sea factible, la propia herramienta de IA lea previamente la documentación del modelo de amenazas de Linux, para alinear sus conclusiones con los criterios ya establecidos por el proyecto. Se trata de reducir malentendidos y evitar que la redacción automática convierta un bug de impacto limitado en una supuesta vulnerabilidad crítica sin base real.

Reproductores, parches y sentido común en la era de la automatización

Además de cómo describir el fallo, la documentación se detiene en la parte más práctica: la generación y validación de reproductores y parches con ayuda de IA. Muchas herramientas modernas pueden crear pequeños programas de prueba o secuencias de comandos que activan el bug, así como sugerir cambios de código para corregirlo, pero no siempre lo hacen de forma fiable.

Desde el kernel se insiste en que, antes de enviar un informe, el investigador debe comprobar personalmente que el reproductor funciona tal y como se describe. Si la secuencia no dispara el fallo, o si la IA no es capaz de generar un método reproducible, la validez del informe queda seriamente en entredicho. Publicar hallazgos sin esa verificación solo añade ruido y consume tiempo de los mantenedores.

Respecto a los parches, el texto destaca que muchas IAs son incluso mejores escribiendo código que evaluando su impacto. Por eso se anima a quienes utilizan estas herramientas a pedirles no solo que identifiquen el problema, sino que también propongan la corrección. Ahora bien, se recalca que el resultado debe revisarse y probarse manualmente antes de enviarlo a las listas de desarrollo.

La guía es tajante en los casos en los que el parche no puede probarse porque depende de hardware exótico, protocolos de red prácticamente desaparecidos o configuraciones extremadamente raras. Si un fallo solo se manifiesta en un entorno tan marginal que nadie puede validarlo con facilidad, es muy posible que no tenga la categoría de vulnerabilidad de seguridad relevante y que no deba consumir el tiempo del canal privado.

Cuando se proponga una corrección, el proyecto recuerda que tiene que cumplir las normas habituales de envío de parches del kernel, incluyendo la etiqueta “Fixes:” señalando el commit concreto que introdujo el bug. También se sugiere aplicar sentido común: si el archivo afectado lleva más de un año sin cambios y lo mantiene una única persona, puede que estemos ante un componente con muy pocos usuarios reales, como controladores de hardware antiguo o sistemas de archivos obsoletos.

En esos supuestos, la recomendación es clara: si el problema es trivial, fácil de detectar y no tiene impacto evidente en entornos típicos, lo más razonable es tratarlo directamente en las listas públicas de desarrollo y no en la lista dedicada a seguridad. De este modo, se reservan los recursos más sensibles para incidentes con consecuencias potencialmente graves.

De la era del fuzzing a la avalancha de IA: lecciones para el software libre

La situación actual recuerda en parte a la época en la que herramientas de fuzzing como syzkaller empezaron a bombardear al kernel con informes de fallos detectados de forma semi-automática. En aquel momento, la comunidad tuvo que aprender a integrar ese flujo continuo de hallazgos en su proceso de desarrollo sin colapsar el trabajo diario.

Con la inteligencia artificial ocurre algo similar, pero a otra escala. Ahora no solo se automatiza la generación de entradas que provocan errores, sino también la redacción de los propios informes, el análisis estático del código y la propuesta de parches. Esto acelera el hallazgo de bugs, pero si no se filtra ni se prioriza bien, también multiplica el número de correos, de discusiones paralelas y de expectativas sobre lo que el equipo del kernel puede absorber.

Dentro del propio ecosistema Linux hay matices en la valoración de este fenómeno. Greg Kroah-Hartman, otro mantenedor clave del kernel, ha señalado que los informes generados por IA han pasado en poco tiempo de ser casi siempre basura a convertirse en contribuciones válidas. Esa visión más optimista convive con la preocupación de Torvalds por el exceso de duplicados y la sobrecarga en la lista de seguridad.

Más que una contradicción, estas posturas reflejan dos caras del mismo proceso de adopción: por un lado, la IA puede ser muy útil para encontrar problemas reales; por otro, si muchas personas lanzan las mismas herramientas sobre el mismo código y remiten los resultados sin filtro, el efecto combinado es una “tormenta” de avisos difícil de gestionar.

Un ejemplo de uso responsable de automatización lo ofrece el propio Kroah-Hartman, que ha dado a conocer sistemas personales para escanear el kernel, generar parches, probarlos y enviarlos siguiendo el flujo estándar del proyecto. La clave es que, en estos casos, el desarrollador asume toda la responsabilidad técnica del ciclo completo, en lugar de limitarse a reenviar sin revisar lo que produce una herramienta.

Todo el movimiento que rodea a Linux 7.1 muestra a un proyecto que, lejos de rechazar la inteligencia artificial, está adaptando sus procesos para que la automatización juegue a favor de la seguridad y no en su contra. Al fijar criterios más estrictos sobre qué es una vulnerabilidad, exigir informes verificables en texto plano y animar a que la IA también contribuya a generar y probar parches, el kernel intenta proteger el tiempo de sus mantenedores, reducir el ruido y centrar los esfuerzos en los errores que realmente pueden comprometer sistemas en producción.

from Linux Adictos https://ift.tt/5fYdTak
via IFTTT

La llegada de Heroic Games Launcher 2.22 supone un nuevo paso para quienes buscan una forma unificada de gestionar sus bibliotecas de juegos en PC sin depender de los clientes oficiales de cada tienda. Esta versión del lanzador de código abierto, muy popular entre usuarios de Linux, Windows y macOS, sigue apostando por ofrecer una experiencia más ligera, centrada en la privacidad y compatible con múltiples tiendas digitales.

Aunque en los últimos años el uso del cliente oficial de Epic o de GOG Galaxy se ha generalizado, una parte importante de la comunidad, especialmente en entornos como Linux o Steam Deck, prefiere alternativas como Heroic. La actualización 2.22 se orienta precisamente a ese perfil de usuario, con mejoras en la gestión de la biblioteca, nuevas funciones para pantallas grandes y cambios internos que elevan los requisitos básicos del sistema, buscando más estabilidad.

Principales novedades de Heroic Games Launcher 2.22

Una de las incorporaciones más visibles en Heroic Games Launcher 2.22 es la posibilidad de editar cualquier juego de la biblioteca. Esto permite modificar elementos como el título que aparece en la lista o las imágenes de portada, algo especialmente útil para quienes quieren tener ordenada una colección grande o diferenciar versiones, mods y ediciones especiales.

Los desarrolladores también han mejorado la gestión de juegos procedentes de instaladores externos. Ahora, incluso para esos proyectos ajenos a la descarga directa desde Epic, GOG o Amazon, es posible asignar imágenes de carátula y presentarlos de forma más homogénea dentro de la biblioteca del lanzador.

Otra novedad destacada es la mejora del modo consola para pantallas grandes. En esta modalidad, pensada para televisores o monitores usados a cierta distancia, la versión 2.22 añade soporte para instalar y actualizar juegos directamente, sin necesidad de volver a la interfaz de escritorio. Esto se alinea con el uso del programa en dispositivos como Steam Deck u otros equipos conectados al salón.

Mejoras en la experiencia de uso y la interfaz en Heroic Games Launcher 2.22

En el apartado de usabilidad, Heroic Games Launcher 2.22 introduce cambios en la gestión de la bandeja del sistema. El icono del programa en el área de notificaciones pasa a funcionar como un conmutador: permite mostrar u ocultar la ventana principal con un solo clic, algo práctico para quienes trabajan con muchas aplicaciones abiertas.

La nueva versión corrige además el funcionamiento de la botón de copiar datos del sistema en la sección de información técnica, que daba problemas en versiones anteriores. Esta opción resulta útil cuando el usuario necesita compartir especificaciones para pedir ayuda o reportar errores. También se ha solucionado el fallo de la botón de detener en la página de cada juego, que en algunos casos no reaccionaba correctamente al intentar parar descargas o ejecuciones.

Entre las opciones de comportamiento, se ha añadido la posibilidad de ocultar la ventana del programa cuando se lanzan juegos mediante enlaces del tipo heroic://. Esto permite iniciar títulos desde accesos directos externos o integraciones de terceros sin que la interfaz principal de Heroic se quede en primer plano.

Filtros y gestión de ofertas en GOG

La versión 2.22 presta especial atención a la integración con GOG.com, una de las tiendas más usadas y con una base de usuarios considerable. En la sección de descuentos integrada dentro de Heroic, se han añadido filtros específicos para productos comprados y para artículos en la lista de deseos.

Gracias a estos filtros, el usuario puede revisar con rapidez qué juegos rebajados ya tiene en su biblioteca y cuáles forman parte de su wishlist, sin tener que ir saltando entre la web de GOG y el cliente. Para quienes siguen de cerca las rebajas periódicas o campañas como las rebajas de verano, este pequeño cambio facilita mucho la toma de decisiones de compra.

Compatibilidad con Ubisoft Connect y mandos de PS5

Uno de los puntos que más llamará la atención a los jugadores es la incorporación de soporte para proyectos gestionados desde Ubisoft Connect. Aunque el cliente de Ubisoft sigue siendo necesario en segundo plano para algunos títulos, Heroic 2.22 permite integrar mejor estos juegos en su biblioteca unificada, de forma que el usuario pueda lanzarlos desde la misma interfaz que el resto de su colección.

En el ámbito de los mandos, la nueva versión introduce una separación más clara para los controladores de PlayStation 5. Esto ayuda a que el programa distinga mejor las entradas y perfiles asociados a los DualSense, algo relevante para quienes alternan entre distintos tipos de gamepad o usan configuraciones personalizadas.

El modo consola, pensado para manejar el programa desde el sofá, también recibe ajustes centrados en el control con mando. Se ha perfeccionado la navegación con gamepad, haciendo más fluida la interacción con los menús y listas de juegos cuando no se utiliza teclado y ratón.

Modo consola y mejoras específicas para Linux y Steam Deck

Heroic Games Launcher se ha consolidado como una de las herramientas de referencia en el ecosistema Linux y Steam Deck, donde no siempre hay clientes oficiales de las tiendas. En este contexto, el modo consola reforzado en la versión 2.22, con instalación y actualización directa de juegos, encaja muy bien con el uso en televisores y en la interfaz tipo consola de los dispositivos portátiles.

El programa integra opciones avanzadas para trabajar con Wine y Proton, las capas de compatibilidad que permiten ejecutar juegos de Windows en Linux. También ofrece soporte para componentes clave como DXVK y VKD3D, que traducen instrucciones de DirectX a Vulkan para mejorar el rendimiento. Estas herramientas pueden configurarse desde Heroic, lo que simplifica la puesta a punto de muchos títulos.

Para quienes utilizan la aplicación en su Steam Deck, la posibilidad de combinar juegos de Epic, GOG, Amazon y ahora Ubisoft Connect en una misma biblioteca supone una vía cómoda de ampliar el catálogo más allá de Steam, sin tener que recurrir a múltiples lanzadores o configuraciones manuales complejas.

Una alternativa consolidada a los clientes oficiales

Heroic Games Launcher se ha consolidado como una alternativa gratuita a clientes como Epic Games Launcher, GOG Galaxy o la aplicación de Amazon Games, especialmente valorada en entornos donde estos programas no ofrecen cliente nativo o resultan más pesados. Para quienes priorizan la ligereza, la privacidad y el control sobre cómo y desde dónde ejecutan sus juegos, la versión 2.22 refuerza esa propuesta con pequeños cambios que, en conjunto, mejoran bastante la experiencia diaria.

Con funciones avanzadas para Linux y Steam Deck, una integración cada vez más completa con las principales tiendas, soporte para proyectos vía Ubisoft Connect y una comunidad activa que participa en la traducción y revisión del código, esta actualización coloca a Heroic Games Launcher 2.22 en una posición sólida como herramienta central para gestionar bibliotecas de juegos y, muy especialmente, entre los usuarios que apuestan por soluciones abiertas y multiplataforma.

from Linux Adictos https://ift.tt/QBmiEMF
via IFTTT

Mozilla ha publicado, a falta de hacerlo oficial, algo que hará a lo largo del día de hoy, Firefox 151 como la nueva versión estable de su navegador, una actualización mensual que llega cargada de cambios visibles y ajustes en segundo plano. El foco se reparte entre el rediseño de la página de nueva pestaña, nuevas opciones de privacidad, mejoras en el visor de PDF y varias funciones orientadas a usuarios avanzados y desarrolladores.

Aunque en esta versión se hablaba de la posible llegada de un decodificador nativo para imágenes JPEG-XL, finalmente esta novedad se retrasa a Firefox 152 beta. Aun así, Firefox 151 supone un paso relevante en la evolución del navegador, especialmente para quienes usan el servicio VPN integrado, la navegación privada, el visor PDF o dependen de su perfil de usuario entre distintos equipos y sistemas operativos.

Nuevo Firefox Home: así cambia la página de nueva pestaña en Firefox 151

Uno de los cambios más visibles es la renovación de la página de nueva pestaña, que pasa a llamarse Firefox Home y adopta un aspecto más pulido. El cambio no es revolucionario, pero introduce un diseño más coherente con el futuro rediseño general del navegador (conocido como Nova), con formas más redondeadas y una sensación de interfaz algo más ligera.

El elemento que más llama la atención es la barra de búsqueda central, ahora con un diseño de «pastilla» más alargado y con esquinas redondeadas. Además, deja de mantenerse fija al hacer scroll, lo que da un poco más de espacio visual al resto de contenidos cuando el usuario se desplaza por la página de inicio.

Las historias recomendadas siguen presentes, pero el botón para seguir temas cambia su presentación: ahora se muestra como un icono de suma situado a la izquierda del encabezado de la sección. El funcionamiento, en esencia, no cambia: se pueden seguir temáticas concretas o ajustar qué tipo de contenidos aparecen en esa zona.

Para quienes consideran este apartado más ruido que otra cosa, Firefox mantiene la posibilidad de ocultar historias concretas o bloquear temas enteros, y también es posible desactivar la personalización basada en el historial de navegación. Esta personalización viene activa por defecto, pero se puede ajustar desde las opciones.

Personalización, accesos directos y nuevo widget del tiempo

Firefox Home también introduce un pequeño lavado de cara en el widget del tiempo (disponible solo en ciertos países), que se adapta al nuevo ancho de la barra de búsqueda. Desaparece la posibilidad de alternar entre vistas simple y detallada: ahora se muestra un recuadro único con la temperatura actual y las máximas y mínimas.

En cuanto a los accesos directos, Mozilla permite mostrar más filas de atajos en la página de inicio. Desde el icono del lápiz se pueden ajustar estos elementos y llegar hasta un máximo de cuatro filas, algo que puede venir bien a quienes usan Firefox como punto de partida para sus webs y servicios más habituales.

Para acompañar este nuevo enfoque visual, Firefox 151 incorpora una serie de fondos de pantalla «nuevos y llamativos» que se pueden elegir para personalizar Firefox Home. El objetivo es aprovechar mejor el espacio que antes quedaba prácticamente vacío y dar opciones a quienes quieren una pantalla de inicio más vistosa.

Ajustes de diseño y primeras pinceladas del rediseño Nova

Más allá de la nueva pestaña, en esta versión empiezan a verse retazos del rediseño Nova en otras partes del navegador. La página de configuración (accesible vía about:preferences) se vuelve más compacta, con los elementos mejor agrupados y un diseño algo más denso.

El buscador interno de la página de ajustes también cambia: la barra de búsqueda de las preferencias ahora ocupa todo el ancho de la columna de configuraciones, en lugar de quedar arrinconada, lo que facilita localizar opciones concretas cuando el usuario no recuerda exactamente en qué apartado se encuentran.

Los widgets experimentales disponibles desde Firefox Labs también se benefician de pequeños retoques visuales. Según explica Mozilla, ahora se integran mejor en el conjunto y dejan de verse tan fuera de lugar respecto al resto del diseño del navegador.

Privacidad: botón rápido para limpiar sesiones privadas y mejor protección contra huellas

En el terreno de la privacidad, Firefox 151 introduce una novedad práctica en el modo de navegación privada: un botón específico para borrar la sesión sin tener que cerrar la ventana. Se trata de un icono con forma de llama en la barra de herramientas que permite eliminar cookies, historial y datos del sitio relativos a la sesión privada abierta.

Al hacer clic en este botón, el navegador muestra un aviso de confirmación y, tras aceptarlo, limpia todos los datos asociados a esa sesión y la deja lista como si se acabase de abrir una ventana privada nueva. La idea recuerda a la función «Fire» del navegador de DuckDuckGo, que también usa una metáfora de fuego para dejar todo a cero, aunque en Firefox no se ha incorporado una animación llamativa.

Además, Mozilla refuerza la protección contra la huella digital del dispositivo (fingerprinting) dentro del modo de Protección Mejorada contra Rastreo en nivel Estándar. Se limita la cantidad de información sobre el sistema y el navegador que las webs pueden recoger, con el objetivo de complicar el seguimiento del usuario a través de diferentes sitios mediante técnicas de identificación pasiva.

Visor PDF de Firefox 151: unir archivos sin salir del navegador

El visor y editor de PDF nativo de Firefox continúa ganando funciones, y en esta versión recibe una de las más útiles: la posibilidad de fusionar varios archivos PDF en un único documento. Esto evita tener que recurrir a aplicaciones externas o servicios web de terceros para tareas sencillas de combinación de documentos.

El proceso es bastante directo: basta con abrir un PDF en el navegador, desplegar la barra lateral y pulsar el icono de suma. Desde ahí se puede elegir otro archivo PDF en el gestor de archivos del sistema. Su contenido se añade al final del documento abierto, y el usuario puede reordenar las páginas o eliminar las que no necesite.

Una vez que se tiene el documento final a gusto de cada uno, solo queda exportar el PDF combinado antes de cerrar la pestaña. Para quienes trabajan con muchos documentos, especialmente en entornos administrativos, académicos o legales, este tipo de funciones integradas puede ahorrar tiempo y reducir la dependencia de programas adicionales.

Traducciones en el propio dispositivo: acceso más directo

Firefox introdujo recientemente una página específica para gestionar las traducciones que se realizan de forma local en el propio dispositivo, sin enviar el texto a servidores externos, a través de la dirección about:translations. Con Firefox 151, el acceso a esta herramienta se simplifica.

Ya no es necesario recordar o escribir manualmente la dirección especial: la página de traducciones se puede abrir desde el menú interno del navegador, concretamente desde la sección “Más herramientas” del menú de la aplicación. Este detalle puede animar a más usuarios a probar las traducciones locales, un aspecto especialmente sensible para quienes priorizan la protección de datos.

Copias de seguridad de perfiles y sincronización entre sistemas

Mozilla refuerza la gestión de perfiles de usuario, un punto crítico cuando se manejan marcadores, extensiones, configuraciones y contraseñas en varios equipos. Firefox 151 habilita la creación de copias de seguridad locales de perfiles en Linux, una opción que ya estaba disponible en Windows desde hace algunas versiones.

Además, estas copias de seguridad ahora pueden restaurarse entre distintas plataformas, por ejemplo, mover un perfil desde macOS a Linux o viceversa, manteniendo temas, complementos y otros ajustes. Esto facilita los cambios de sistema operativo sin perder el entorno de trabajo habitual del navegador, algo interesante para usuarios que alternan entre entornos de escritorio distintos.

Mejoras específicas para macOS y ajustes por región

En macOS, Firefox 151 incorpora compatibilidad con Universal Clipboard, lo que permite copiar y pegar contenido de forma más transparente entre dispositivos del ecosistema Apple, como un Mac y un iPhone o iPad. También se introducen menús nativos integrados en la propia página, lo que busca que la experiencia siga más de cerca las convenciones de diseño del sistema de Apple.

Por otro lado, en Europa se nota un pequeño guiño regional: se habilita la función de autocompletado de direcciones para usuarios de Países Bajos. Esto acelera el relleno de formularios en compras online, registros de servicios y trámites digitales. Es previsible que esta función se vaya extendiendo de forma gradual a otros, aunque Mozilla no detalla un calendario concreto en las notas de esta versión.

En el caso de Windows, se menciona un ajuste en los avisos de geolocalización, con cambios en cómo se muestran las peticiones de ubicación a los usuarios. Aunque el comportamiento básico sigue siendo el mismo (pedir permiso antes de compartir la ubicación), Mozilla recalibra la experiencia para alinearla mejor con las expectativas de seguridad y privacidad en este sistema.

Novedades para desarrolladores y compatibilidad web

Con esta API, los desarrolladores pueden abrir una ventana siempre visible que contenga HTML arbitrario, no solo un vídeo. Esto habilita usos como controles personalizados en videollamadas, paneles de información adicionales o herramientas flotantes que acompañen al usuario mientras navega por otras páginas. Firefox se alinea así con navegadores como Chrome, que incorporaron esta capacidad a partir de versiones como la 116.

Entre el resto de cambios orientados a desarrollo, destaca la activación de las restricciones de acceso a red local para todos los usuarios, un paso importante para reducir riesgos de seguridad en aplicaciones web que podrían intentar comunicarse con dispositivos internos sin conocimiento del usuario.

También se mejora el soporte del Fullscreen Keyboard Lock API, que ahora admite un argumento en la llamada a requestFullscreen, permitiendo un mayor control sobre cómo y cuándo se bloquea el teclado en interfaces a pantalla completa. Por su parte, las reglas CSS @container amplían su sintaxis y aceptan listas de condiciones de consulta y estilos combinados, algo muy útil para diseños responsivos más flexibles.

En el ámbito del hardware, Firefox 151 habilita soporte para la Web Serial API en ciertos microcontroladores, incluido el Raspberry Pi Pico. Esto abre la puerta a aplicaciones web que interactúan directamente con dispositivos conectados por puerto serie, una posibilidad interesante para proyectos educativos, de domótica o de prototipado rápido.

Disponibilidad de Firefox 151 y opciones de instalación

Las compilaciones oficiales de Firefox 151.0 están disponibles para descarga directa desde los servidores de Mozilla, y pronto en la web oficial del proyecto. En Windows y macOS, la actualización llega como un parche interno que se descarga y aplica desde el propio navegador, salvo que el usuario haya desactivado expresamente las actualizaciones automáticas. En entornos de escritorio Linux, la situación es algo más variada según la distribución y el formato elegido.

En Ubuntu, donde Firefox se distribuye por defecto en formato Snap, la actualización a la versión 151 se realiza en segundo plano, sin que el usuario tenga que intervenir, y se aplica en cuanto se reinicia el navegador. Quien prefiera el formato Flatpak puede instalarlo desde Flathub y actualizar más tarde mediante el comando flatpak update o a través de aplicaciones gráficas como Bazaar, disponible en los repositorios de Ubuntu 26.04.

Para distribuciones como Linux Mint, la actualización se gestiona normalmente mediante la herramienta Mint Update o a través de la línea de comandos con apt. En cualquier caso, las notas de lanzamiento y el apartado de seguridad detallan los parches incluidos, lo cual es relevante para administradores de sistemas y usuarios que necesitan justificar actualizaciones por motivos de cumplimiento normativo.

Con Firefox 151, Mozilla refuerza piezas clave del navegador sin grandes estridencias: un Firefox Home más trabajado, mejoras claras en privacidad, un visor PDF más completo y nuevas APIs que apuntan tanto a usuarios finales como a desarrolladores. La versión se siente como un paso intermedio sólido hacia el futuro rediseño Nova, con avances que, aunque discretos, resultan prácticos en el uso diario y mantienen al navegador bien posicionado en el ecosistema de software libre.

from Linux Adictos https://ift.tt/C2zbOev
via IFTTT

La comunidad de Debian ha publicado la versión 13.5, un nuevo punto de actualización de la rama Trixie que se centra, sobre todo, en reforzar la seguridad del sistema y pulir detalles técnicos. No se trata de una edición con grandes cambios visibles para el usuario final, sino de una revisión pensada para mantener la distribución estable, fiable y al día de los últimos parches. Esta iteración ha llegado dos meses después de la anterior.

Este lanzamiento incorpora correcciones de seguridad acumuladas tanto para el núcleo Linux como para decenas de paquetes de espacio de usuario que se utilizan a diario en servidores y equipos de escritorio. Además, se han introducido pequeños ajustes de compatibilidad y estabilidad que buscan que las futuras actualizaciones de software lleguen con menos sobresaltos.

Nueva revisión de Debian Trixie centrada en seguridad

Con Debian 13.5, la rama Trixie recibe un conjunto de actualizaciones de seguridad para el kernel de Linux que corrigen vulnerabilidades recientemente identificadas. Estos parches son especialmente relevantes para entornos de producción y administración pública, donde Debian es una opción muy extendida por su énfasis en la estabilidad y el soporte a largo plazo.

Junto al núcleo, se han actualizado docenas de paquetes de usuario con el objetivo de cerrar puertas a posibles ataques, mejorar el comportamiento en situaciones límite y reducir la probabilidad de errores graves. Esta filosofía de mantener un ritmo constante de revisiones permite que quienes gestionan sistemas en organizaciones tengan una base de software más robusta sin necesidad de grandes migraciones.

Corrección de vulnerabilidades críticas en aplicaciones clave

Una de las piezas destacadas de esta revisión es la solución a un fallo de escalada de privilegios en Bubblewrap. Este tipo de vulnerabilidad podría permitir que un usuario o proceso con permisos limitados obtuviera más control del previsto sobre el sistema, de modo que su corrección es prioritaria en entornos multiusuario y de contenedores donde se busca un aislamiento más estricto.

También se ha resuelto un problema de ejecución de código en Cockpit, la interfaz web de administración de sistemas. Un error de este tipo puede traducirse en la posibilidad de que un atacante ejecute órdenes no autorizadas si consigue explotar la vulnerabilidad, por lo que la actualización es especialmente recomendable en servidores y paneles de gestión accesibles desde redes corporativas o Internet.

Varios paquetes afectados por vulnerabilidades de desbordamiento de búfer han recibido parches específicos. Estos problemas, aunque a veces difíciles de explotar, pueden provocar desde caídas inesperadas de aplicaciones hasta la ejecución de código malicioso, por lo que su corrección contribuye a endurecer la seguridad general del sistema.

Otro ajuste relevante se ha aplicado al editor de texto nano, donde se ha corregido un exceso de permisos en determinadas situaciones. Aunque pueda parecer un detalle menor, un control inadecuado de permisos puede abrir puertas a modificaciones no deseadas en archivos sensibles, algo que en servidores y sistemas compartidos resulta especialmente delicado.

En el ámbito web, Debian 13.5 incorpora parches para componentes de PHP afectados por posibles ataques de denegación de servicio. Estas vulnerabilidades podrían permitir que un atacante saturase el servicio mediante peticiones especialmente diseñadas, ralentizando o incluso tumbando aplicaciones web críticas para empresas, administraciones u organizaciones.

El servidor gráfico X.Org Server también forma parte del lote de actualizaciones, con distintas correcciones de seguridad destinadas a reducir vectores de ataque en sistemas que aún dependen de esta tecnología. Aunque en muchos entornos se esté migrando hacia alternativas como Wayland, la presencia de X.Org sigue siendo muy común, sobre todo en instalaciones de escritorio tradicionales.

Mejoras de compatibilidad y estabilidad técnica en Debian 13.5

Más allá de la seguridad, Debian 13.5 introduce actualizaciones en varios paquetes para mejorar la compatibilidad con Python 3.13. Este paso resulta importante para desarrolladores y administradores que quieren ir preparando sus aplicaciones y entornos de trabajo para futuras versiones del lenguaje sin salir de un sistema operativo estable.

En el terreno de la arquitectura RISC-V de 64 bits, la distribución corrige instrucciones ilegales en el código EFI de GRUB. Este arreglo será bienvenido en laboratorios, universidades y centros de investigación que estén apostando por RISC-V para proyectos de hardware abierto, ya que reduce los problemas a la hora de arrancar y gestionar estos sistemas.

Además de estas correcciones concretas, el lanzamiento suma distintos ajustes menores repartidos por el sistema, cuyo objetivo es mejorar la experiencia de uso sin introducir cambios bruscos. Se trata de arreglos que, aunque pasen desapercibidos para la mayoría de usuarios, ayudan a mantener la coherencia y solidez del conjunto.

Disponibilidad y actualización de Debian 13.5

Las imágenes actualizadas y los paquetes necesarios para instalar o actualizar a Debian 13.5 ya están disponibles a través del portal oficial Debian.org y los servidores espejo. Los equipos que ya ejecutan Debian Trixie pueden obtener esta revisión mediante los mecanismos habituales de actualización del sistema, sin necesidad de reinstalar desde cero.

En entornos profesionales, se recomienda que los responsables de sistemas planifiquen la implantación de los parches siguiendo las políticas internas de cada organización, pero sin posponer en exceso la actualización, dado el carácter de las vulnerabilidades corregidas. Para usuarios domésticos, basta con aplicar las actualizaciones desde el gestor de paquetes o la herramienta gráfica habitual.

Con esta nueva revisión puntual, Debian vuelve a reforzar su apuesta por la estabilidad, la seguridad y el mantenimiento continuado, tres elementos especialmente valorados en administraciones públicas, universidades y empresas. Aunque no introduce grandes novedades visibles, esta versión 13.5 permite que la rama Trixie siga siendo una opción fiable tanto para servidores como para equipos de uso diario.

from Linux Adictos https://ift.tt/0MNKE8z
via IFTTT

WineHQ ha lanzado recientemente una nueva versión bisemanal de su software, diseñada para ejecutar aplicaciones de Windows sobre otros sistemas operativos. En esta ocasión, el foco principal son los usuarios de Linux, que continúan beneficiándose de un proyecto que avanza a buen ritmo cada ciclo.

WINE 11.9 aparece como una versión de desarrollo que marca la mitad del ciclo actual, con un historial de alrededor de 20 actualizaciones anuales. Entre las novedades más destacadas se encuentra la incorporación de la librería SQLite, un soporte inicial para hilos del sistema y la suspensión de hilos en el código emulado en ARM64. Además, se han realizado mejoras en la compatibilidad con VBScript y, como de costumbre, se han aplicado numerosas correcciones de errores.

En números, esta entrega corrige 24 bugs y reporta 196 cambios, continuando la racha de avances que siguieron a la versión 11.8, publicada hace dos semanas. Estas mejoras reducen problemas de compatibilidad y aumentan la estabilidad en escenarios reales de uso.

Bugs corregidos en WINE 11.9 (selección):
– El instalador de Lotus Notes 8.x quedó estable tras evitar una excepción del analizador SAX y la preservación de saltos de línea.
– Cierre inesperado de Logos 9 durante la indexación por formato de cadena no válido.
– Ejecutabilidad de programas de consola como “hello world” corregida; antes aparecía un fallo de página no controlado.
– Problemas de renderizado en la interfaz de WinSCP.
– Aserciones en VBScript al manipular arrays multidimensionales por índices.
– Compilación de llamadas a subrutinas en VBScript cuando el argumento contiene multiplicación.
– Conversión de números en formato cadena a valores ASCII en lugar del valor interpretado.
– El gestor de imágenes del SDK de Windows (rebase) se cerraba por la función no implementada imagehlp.dll.ReBaseImage64.
– Mejora visual de la barra de progreso del instalador de Homesite 5.5.
– Interfaz de GOM Player con elementos que no respondían a clics.
– Ventana de Wargaming Game Center no aparecía o era invisible.
– Problemas al guardar proyectos en GraphPad Prism 9 si msxml6 no estaba instalado.
– Fallos en scanf scanset relacionados con rangos de caracteres altos en C.
– Cierre inesperado de GXSCC al arrastrar un MIDI válido.
– Bloqueos en ExamDiff Pro al llegar al final del archivo.
– Fallos en winhttp: DOAXVV en la pantalla de título.
– Soporte para SEC_WINNT_AUTH_IDENTITY_EX en AcquireCredentialsHandle.
– Errores en Command & Conquer 3 y Red Alert 3 al mostrar el mismo tipo de error.
– Arreglos en d3d9 por la ausencia de patrones de bytes en la vtable de MSVC.
– Correcciones en d2d1 para arcos Bézier (d2d_arc_to_bezier, d2d_figure_add_arc, d2d_arc_transform).
– RemoveDirectoryW falla tras finalizar un subproceso con ERROR_SHARING_VIOLATION.
– Los volúmenes no retoman FILE_SUPPORTS_OPEN_BY_FILE_ID.
– Regresión: cierre inesperado con fallo de segmentación al iniciar Photoshop CS2.
– SteelSeries GG 110.0 se cierra al arrancar durante la ejecución de .NET System.Security.Cryptography.X509Certificates.CertificateRequest..ctor.

Ya disponible para descarga: WINE 11.9 puede descargarse desde el enlace de la página oficial. En la página de descargas también se ofrece información detallada sobre cómo instalar estas y otras versiones en Linux, macOS y Android.

Mirando hacia el futuro cercano, la agenda sugiere que en dos semanas podría estar disponible WINE 11.10, con decenas de cambios orientados a preparar WINE 12.0 para principios de 2027. Este ritmo de lanzamientos se mantiene estable a lo largo del año, con el objetivo de ir consolidando mejoras antes de avanzar hacia nuevas etapas de desarrollo.

Para aquellos interesados en probar la versión, el lanzamiento recomienda aprovechar el botón de descarga proporcionado en la página oficial, que facilita la obtención del paquete fuente y las instrucciones de instalación. Se espera que el ciclo de desarrollo continúe aportando mejoras sustanciales para la compatibilidad de aplicaciones Windows en entornos Linux y otros sistemas operativos compatibles.

from Linux Adictos https://ift.tt/mIY8GdC
via IFTTT

La reciente cadena de fallos de seguridad en Linux ha sumado un nuevo capítulo con la aparición de ssh-keysign-pwn, una vulnerabilidad que se añade a otras como Dirty Frag, Copy Fail o Fragnesia. Este problema reaviva la atención sobre la seguridad del kernel y la necesidad de mantener los sistemas al día, especialmente en entornos profesionales y de administración pública. En los últimos días se observa un aumento notable de investigaciones centradas en el kernel Linux, las cuales están destapando errores que permiten desde escaladas locales de privilegios hasta el acceso indebido a información crítica. ssh-keysign-pwn destaca porque, aunque el atacante no obtenga directamente permisos de superusuario, consigue un resultado igualmente preocupante: la lectura de archivos propiedad de root desde cuentas sin privilegios.

Qué es ssh-keysign-pwn y por qué es tan preocupante
El fallo conocido como ssh-keysign-pwn es una vulnerabilidad en el kernel Linux que posibilita a un usuario sin privilegios leer archivos que pertenecen a la cuenta root. A diferencia de otros exploits más complejos que requieren condiciones muy específicas o carreras de concurrencia difíciles de reproducir, este problema se considera especialmente delicado porque abre la puerta a la exposición silenciosa de información sensible.
Según los primeros análisis técnicos, la vulnerabilidad se enmarca dentro de la misma oleada de problemas que han salido a la luz recientemente en el ecosistema Linux, como Dirty Frag, Copy Fail o Fragnesia. En estos casos, se explotan errores lógicos en componentes internos del kernel para lograr efectos no previstos por los desarrolladores, como escrituras arbitrarias sobre páginas de memoria marcadas como de solo lectura o la lectura de datos que deberían estar completamente protegidos.

Alcance de la vulnerabilidad en el kernel Linux
Una de las características más alarmantes de ssh-keysign-pwn es su amplia difusión. Los reportes publicados indican que todas las versiones del kernel Linux se ven afectadas por el fallo, incluido el estado más reciente del código en Git en el momento de su descubrimiento. Esto implica que no se trata de un problema aislado de una rama antigua o de una configuración muy específica, sino de una debilidad que ha acompañado al kernel durante varias versiones.
El impacto potencial es significativo, ya que la vulnerabilidad permite el acceso no autorizado a archivos propiedad de root. En la práctica, esto puede traducirse en la lectura de ficheros con secretos de configuración, claves privadas, credenciales o información sensible del sistema que, combinada con otros vectores de ataque, podría facilitar movimientos laterales, escaladas de privilegios o la preparación de ataques dirigidos contra servicios concretos.
Para las organizaciones que dependen de Linux en entornos críticos, como centros de datos, instituciones públicas o empresas que operan infraestructuras en la nube, este tipo de fallo puede afectar tanto a la integridad como a la confidencialidad de los datos alojados en sus servidores. Aunque la explotación requiere acceso local, en entornos multiusuario o con servicios expuestos puede convertirse en un punto de apoyo para intrusiones más graves.

Descubrimiento de ssh-keysign-pwn y respuesta de la comunidad de seguridad
La vulnerabilidad ssh-keysign-pwn ha sido reportada por investigadores de la firma de seguridad Qualys, una compañía conocida por su trabajo en auditoría y análisis de vulnerabilidades a gran escala. Su investigación ha permitido identificar cómo un usuario sin privilegios podría aprovecharse de un comportamiento concreto del kernel para leer archivos que deberían estar reservados exclusivamente a root.
Tras la notificación responsable, los desarrolladores del kernel Linux han trabajado en un parche que ya ha sido integrado en la rama principal (mainline) del proyecto. La corrección pasa por ajustar de manera precisa el comportamiento de determinadas llamadas y rutas internas del kernel, en particular con relación a cómo se maneja el acceso y la inspección de procesos, de forma que se bloquee el escenario que hacía posible el exploit.
Como parte de la respuesta coordinada, se ha puesto a disposición de la comunidad documentación técnica y análisis detallados tanto del exploit como del fix. Esta información se ha publicado en un repositorio público de GitHub, lo que permite a administradores de sistemas, equipos de seguridad y desarrolladores revisar con calma cómo funciona el ataque y qué cambios introduce el parche, facilitando su validación e integración en distintas distribuciones.

Detalles técnicos de ssh-keysign-pwn: cambios en el comportamiento de ptrace
Uno de los elementos clave de la corrección desarrollada por los mantenedores del kernel es la modificación del comportamiento de ptrace, la interfaz que se utiliza habitualmente para depurar procesos o monitorizar su ejecución. Según los datos disponibles, el exploit se apoyaba en una combinación específica de operaciones que permitían sortear las comprobaciones habituales y terminar accediendo a contenidos de archivos propiedad de root.
El nuevo parche introduce restricciones adicionales y ajustes en la lógica interna del kernel para impedir que se materialice ese escenario. Aunque los detalles de bajo nivel son complejos y van dirigidos principalmente a desarrolladores y expertos en seguridad, la idea de fondo es que se cierran las vías que permitían el uso indebido de mecanismos de depuración y observación de procesos para romper el aislamiento entre usuarios sin privilegios y recursos propiedad de root.
Este tipo de correcciones suele ir acompañado de una revisión más amplia de las rutas de código relacionadas, para reducir el riesgo de que existan variantes del mismo problema. No obstante, como se ha visto con Dirty Frag, Copy Fail o Fragnesia, la superficie de ataque del kernel Linux es enorme, por lo que resulta razonable esperar que en los próximos meses sigan apareciendo nuevas investigaciones y parches asociados.

Recomendaciones prácticas para administradores de sistemas
Para administradores de sistemas y responsables de seguridad, los pasos a seguir ante ssh-keysign-pwn pasan por una combinación de acciones inmediatas y medidas a medio plazo. En el corto plazo, la prioridad es asegurarse de que todos los sistemas afectados reciban el kernel corregido tan pronto como los repositorios de la distribución lo ofrezcan.
Mientras tanto, conviene revisar qué usuarios tienen acceso local a los servidores y equipos Linux, ya que el exploit requiere partir de una cuenta sin privilegios en el sistema. Reducir al mínimo las cuentas innecesarias, aplicar el principio de privilegio mínimo y monitorizar los accesos puede ayudar a limitar el impacto de un posible intento de explotación.
Adicionalmente, es buena práctica mantener un seguimiento activo de las listas de correo y canales oficiales de seguridad de las distribuciones Linux utilizadas, así como de etiquetas o secciones específicas dedicadas a vulnerabilidades en medios especializados. Esta vigilancia facilita reaccionar con rapidez cuando aparecen nuevos fallos como ssh-keysign-pwn o Fragnesia.

Transparencia, investigación continua y papel de la comunidad
El caso de ssh-keysign-pwn vuelve a poner de relieve el papel clave que juega la comunidad de desarrolladores e investigadores en el ecosistema Linux. La combinación de empresas de seguridad, mantenedores del kernel y distribuidores permite que vulnerabilidades graves se identifiquen, documenten y corrijan en plazos relativamente ajustados.
La publicación de análisis técnicos en repositorios públicos ayuda, además, a que otros expertos puedan revisar los hallazgos, reproducir los entornos de prueba y evaluar el alcance real de los exploits. Esta transparencia, aunque en ocasiones pueda parecer que expone en exceso los detalles de los fallos, contribuye a mejorar la robustez general del sistema, ya que anima a una revisión constante del código y a la búsqueda proactiva de errores similares.
En un momento en el que Linux se ha consolidado como pilar de buena parte de la infraestructura digital, este tipo de incidentes también sirve como recordatorio de que ningún sistema es infalible. Las organizaciones que dependen de Linux deben asumir que la gestión de vulnerabilidades es un proceso continuo, no una tarea puntual que se resuelve con un único parche.
La aparición de ssh-keysign-pwn, junto con vulnerabilidades emparentadas como Dirty Frag, Copy Fail y Fragnesia, dibuja un panorama en el que la seguridad del kernel Linux está bajo escrutinio constante. Mantener los sistemas actualizados, reforzar los controles de acceso, seguir de cerca las publicaciones de parches y apoyarse en la información técnica disponible se ha convertido en una rutina imprescindible para minimizar riesgos y conservar la confidencialidad e integridad de los datos en servidores y equipos que ejecutan Linux.

from Linux Adictos https://ift.tt/eAymVxD
via IFTTT

Si usas Linux a diario pero sigues dependiendo de aplicaciones de Windows para trabajar, es muy probable que te hayas peleado con máquinas virtuales lentas, configuraciones raras de Wine o soluciones que prometen mucho y luego se rompen a la mínima. En ese contexto aparece Winpodx, un proyecto open source que está llamando bastante la atención porque ofrece justo lo que muchos llevaban años pidiendo: abrir programas de Windows en Linux como si fueran ventanas nativas, sin historias raras.

Winpodx se presenta como una pieza clave para quienes viven entre Linux y Windows: desarrolladores, equipos técnicos, administradores de sistemas o simplemente usuarios avanzados que quieren tener lo mejor de los dos mundos sin cambiar de sistema operativo. En lugar de ser “otra máquina virtual más”, apuesta por contenedores y una integración profunda con el escritorio Linux, hasta el punto de que los iconos de las apps de Windows aparecen en tu menú de aplicaciones y se asocian a tipos de archivo como si fueran nativas.

¿Qué es Winpodx y por qué todo el mundo habla de ello?

Winpodx es un proyecto de código abierto (licencia MIT) creado por kernalix7 y publicado en GitHub, cuyo objetivo es ejecutar aplicaciones de Windows en Linux con la máxima integración posible y la mínima fricción. A diferencia de Wine o CrossOver, no intenta traducir llamadas de la API de Windows al entorno Linux, sino que levanta un Windows real dentro de un contenedor y solo te enseña las ventanas de las aplicaciones en tu escritorio.

La diferencia clave es que Winpodx usa contenedores Docker/Podman en lugar de VMs completas. Por debajo, parte de la imagen dockur/windows para levantar un entorno Windows optimizado, y utiliza FreeRDP RemoteApp (RAIL) para mostrar cada app como una ventana separada, con su icono, su entrada en el menú y su propia asociación de archivos. Eso significa que puedes hacer clic en el icono de Word en tu menú de aplicaciones de GNOME, KDE, Sway o Hyprland, y se abrirá una ventana “normal” de Word como si fuera una app de Linux más.

Esta aproximación lo coloca en una especie de punto medio: más compatible que Wine y más ligero e integrado que una máquina virtual clásica. No tienes que descargar manualmente ISOs, pelearte con configuraciones de RDP o lidiar con escritorios remotos a pantalla completa. El proyecto busca que el usuario solo vea “haz clic en el icono y arranca la app de Windows”, y todo el follón técnico se quede escondido en la trastienda.

Arquitectura técnica de Winpodx: cómo funciona por dentro

La arquitectura de Winpodx se apoya en tres bloques principales que trabajan en conjunto para crear la ilusión de que las apps de Windows son nativas en Linux: el contenedor de Windows, el uso de FreeRDP RemoteApp y la capa de control (CLI + GUI Qt6) en el host.

Contenedor de Windows con dockur/windows

El corazón del sistema es un entorno Windows ejecutándose dentro de un contenedor basado en la imagen dockur/windows. Esta imagen sirve como base para desplegar una instalación de Windows que se somete a un proceso automatizado: descarga de ISO oficial de Microsoft, ejecución de Sysprep, aplicación de ajustes OEM y una fase de “debloat” donde se recortan servicios y componentes innecesarios (telemetría, anuncios, Cortana, indexación de búsqueda, etc.) para ganar rendimiento.

Ese contenedor se integra con motores como Podman (por defecto), Docker o incluso libvirt/KVM según la configuración, y se trata como otro servicio más en tu infraestructura de contenedores. La idea es que puedas orquestarlo, monitorizarlo y hacer logging con las mismas herramientas que ya usas en tu stack.

FreeRDP RemoteApp: ventanas de Windows como si fueran nativas

Para proyectar las aplicaciones de Windows al escritorio Linux, Winpodx recurre a FreeRDP con soporte RemoteApp (RAIL). En lugar de mostrar un escritorio completo remoto, RAIL se encarga de que cada aplicación sea una ventana independiente, con sus bordes, botones de cerrar/minimizar y gestión normal en el gestor de ventanas de Linux.

Winpodx configura automáticamente los parámetros de FreeRDP, incluyendo audio vía ALSA, portapapeles bidireccional, impresoras compartidas y acceso a carpetas (por ejemplo, el directorio personal se expone como \\tsclient\home). Además, las unidades USB conectadas en el host se montan dentro del Windows invitado con letras de unidad (E:, F:, etc.), utilizando un FileSystemWatcher del lado Windows que reacciona incluso a unidades conectadas después de arrancar la sesión.

CLI y GUI Qt6 para controlarlo todo

En el lado de Linux, Winpodx ofrece tanto una línea de comandos bastante completa como una interfaz gráfica basada en Qt6. La CLI incluye subcomandos para crear y gestionar el contenedor, lanzar aplicaciones, refrescar el catálogo de software instalado, realizar comprobaciones de salud (RDP, disco, agente interno, edad de la contraseña, etc.) o controlar el modo de instalación (online y offline).

La GUI Qt6 agrupa todo esto en varias secciones: Apps, Configuración, Herramientas, Terminal integrada e Información, además de un icono de bandeja del sistema más ligero para tener el servicio siempre a mano. Esto permite tanto a usuarios avanzados como a perfiles menos técnicos gestionar Winpodx sin necesidad de memorizar comandos.

Funciones avanzadas: multi-sesión, automatización y seguridad

Más allá de la idea básica de “abre apps de Windows en Linux”, Winpodx incorpora un buen número de detalles técnicos pensados para que la experiencia sea robusta y segura, algo especialmente importante en entornos de trabajo serios.

rdprrap y soporte RDP multi-sesión

Uno de los puntos más delicados de usar Windows Desktop como servidor de RemoteApp es el límite tradicional de una única sesión RDP simultánea. Para resolverlo, el autor de Winpodx desarrolló rdprrap, una reimplementación en Rust de RDPWrap (proyecto original ya sin mantenimiento y distribuido como binarios C++ difíciles de auditar) que levanta ese límite y permite hasta 10 sesiones independientes.

Este componente se instala de manera desatendida durante la preparación del Windows, con verificación de integridad mediante SHA256 fijado, y está licenciado también bajo MIT. Gracias a él, puedes abrir varias aplicaciones de Windows en paralelo sin que una te robe la sesión de la otra, algo crucial si diferentes procesos o usuarios necesitan conectarse al mismo entorno.

Rotación de contraseñas, suspensión automática y salud del sistema

Para no dejar el sistema abandonado desde el punto de vista de la seguridad, Winpodx implementa rotación automática de contraseñas cada 7 días. Genera contraseñas de 20 caracteres de forma criptográficamente segura y aplica un mecanismo de reversión atómica por si algo sale mal durante el cambio, evitando quedarse bloqueado sin acceso.

En cuanto al consumo de recursos, el contenedor se suspende automáticamente cuando no se está utilizando, reduciendo el uso de CPU y memoria, y vuelve a arrancar en el siguiente lanzamiento de una app. La herramienta también fuerza la resincronización del reloj de Windows tras suspensiones del host para evitar problemas de tiempo.

Además, el comando winpodx check permite lanzar un conjunto de health checks para verificar el estado general: contenedor, servicio RDP, agente interno HTTP, espacio en disco y otras métricas útiles para equipos de operaciones o administradores.

Gestión de DPI, audio, portapapeles y periféricos

Para encajar bien en escritorios modernos, Winpodx detecta automáticamente la escala de HiDPI leyendo información de GNOME, KDE, Sway, Hyprland, Cinnamon e incluso xrdb, y ajusta la configuración de RDP para que las aplicaciones de Windows no se vean ni diminutas ni gigantes.

El soporte de audio y portapapeles bidireccional está activado por defecto, lo que significa que puedes oír el sonido de las apps de Windows y copiar/pegar texto e imágenes entre ambos entornos. Las impresoras configuradas en Linux se comparten de forma automática y las unidades USB se mapean en el invitado mediante el mecanismo de FileSystemWatcher, como ya se ha mencionado.

Reverse-open: apps de Linux visibles desde Windows

A partir de la versión 0.5.0, Winpodx introduce una característica muy llamativa: reverse-open, que expone las aplicaciones de Linux dentro del menú “Abrir con…” del Windows invitado. De esta forma, la integración deja de ser unidireccional y se convierte en un auténtico ida y vuelta.

Con reverse-open activo, cuando haces doble clic sobre un archivo dentro de Windows (por ejemplo, un .txt o un .md) y eliges una app de Linux como Kate, se abre el editor en el host Linux, trabajando sobre la ruta real del fichero sin duplicados raros. Los iconos de las apps se muestran correctamente tanto en el menú corto como en el diálogo completo de “Elegir otra aplicación”, lo que hace que la experiencia sea muy natural para el usuario.

Técnicamente, esto funciona gracias a un agente HTTP autenticado con bearer token que corre dentro del Windows invitado en 127.0.0.1:8765 para el canal host→guest, combinado con un listener en el host que procesa peticiones JSON escritas por pequeños shims en Rust dentro del invitado para la dirección contraria. El pipeline host→guest es el mismo que en versiones anteriores (0.3.x), y se ha extendido para soportar esta nueva funcionalidad.

Instalación y configuración de Winpodx en Linux

Una de las grandes bazas del proyecto es que la instalación es prácticamente “de un comando”. Para la mayoría de distribuciones soportadas, basta con abrir una terminal y lanzar:

curl -fsSL https://ift.tt/5vjn7kB | bash

Ese script se encarga de detectar la distribución, instalar las dependencias necesarias (como Podman u otros runtimes de contenedores), preparar el entorno Windows, configurar FreeRDP RemoteApp y registrar las aplicaciones en el menú del escritorio. El primer despliegue suele tardar entre 5 y 10 minutos porque incluye la descarga de la ISO de Windows, el proceso de Sysprep y la aplicación de la configuración automática.

Durante este tiempo, se puede monitorizar el progreso con el comando winpodx pod wait-ready –logs, que muestra el log en directo. Una vez listo, al hacer clic por primera vez en un icono de app de Windows en tu menú, Winpodx termina de provisionar lo que falte, genera entradas de escritorio y lanza la aplicación sin que tengas que tocar ficheros de configuración a mano.

Distribuciones soportadas y paquetes

Además del instalador vía curl, Winpodx publica paquetes específicos para varias distribuciones cuando se hace un push de una nueva etiqueta (v*.*.*). A día de hoy, la compatibilidad incluye:

• openSUSE Tumbleweed, Leap 15.6, Leap 16.0 y Slowroll, usando zypper, con estado “Tested”.
• Fedora 42 y 43, con soporte vía dnf.
• Debian 12/13 y Ubuntu 24.04/25.04/25.10, integrados en apt.
• AlmaLinux, Rocky y RHEL 9/10, también mediante dnf.
• Arch Linux y Manjaro, con paquetes en pacman/AUR.
• NixOS (y Nix en cualquier distro), a través de flakes de Nix.

La documentación oficial detalla todas las rutas de instalación en ficheros como INSTALL.md (incluyendo modos offline/air‑gapped, instalación desde código fuente, fijado de versiones y desinstalación), así como la referencia de CLI y GUI (USAGE.md), el listado de características (FEATURES.md), arquitectura (ARCHITECTURE.md), comparativas (COMPARISON.md), historial de cambios (CHANGELOG.md), guías de contribución (CONTRIBUTING.md) y el proceso de seguridad (SECURITY.md).

Problemas frecuentes durante la instalación

En entornos reales ya se han detectado algunos errores típicos y sus soluciones. Por ejemplo, si aparece un mensaje del tipo “Podman no está instalado”, toca instalarlo manualmente usando el gestor de paquetes de tu distro (en Ubuntu, por ejemplo, sudo apt install podman). Otro problema habitual es que el entorno Windows no termine de arrancar; en estos casos suele deberse a falta de recursos, y conviene asegurarse de disponer al menos de 4 GB de RAM y unos 20 GB de espacio libre en disco.

Si notas que no hay audio en las aplicaciones de Windows, Winpodx ofrece comandos de ayuda (por ejemplo, habilitar o revisar los ajustes de sonido desde su CLI o la GUI), y en casos más rebeldes puede ser necesario revisar la configuración de ALSA o PipeWire en el host. Gran parte de estos escenarios están cubiertos en la documentación y en la sección de issues del repositorio GitHub.

Descubrimiento automático y asociación de aplicaciones

Uno de los grandes puntos fuertes de Winpodx es que no se limita a exponer un escritorio remoto: se preocupa por descubrir y registrar todas las aplicaciones de Windows instaladas para que aparezcan en el menú de aplicaciones de Linux con sus iconos reales.

En el primer arranque del invitado, Winpodx escanea rutas típicas como Registry App Paths, accesos del menú Inicio, aplicaciones UWP/MSIX y gestores como Chocolatey o Scoop, y genera entradas de escritorio (.desktop) con la configuración adecuada de WM_CLASS y StartupWMClass. Esto permite que las ventanas se agrupen correctamente en el dock o barra de tareas y que las asociaciones de archivo funcionen de forma natural: si haces doble clic en un .docx desde tu gestor de archivos de Linux, se abrirá Word dentro de Winpodx.

Si más adelante instalas nuevas aplicaciones dentro del Windows contenerizado, basta con ejecutar winpodx app refresh (o pulsar el botón de “Refresh” en la GUI) para que vuelva a escanear el sistema y registre las nuevas entradas. Así, cualquier cambio en el software de Windows se refleja de manera bastante transparente en tu entorno de escritorio.

Comparativa con Wine, CrossOver, VMs y WSL

Para valorar si Winpodx tiene sentido en tu caso, es importante entender en qué se diferencia de Wine, CrossOver, máquinas virtuales tradicionales y WSL, que son las opciones más habituales para mezclar entornos Windows y Linux.

Wine y CrossOver: capa de compatibilidad ligera pero irregular

Tanto Wine como CrossOver funcionan como una capa de compatibilidad que traduce llamadas del sistema de Windows a Linux. Su gran ventaja es que consumen relativamente pocos recursos, porque no hay un Windows real ejecutándose detrás. Pero esta aproximación tiene un coste en compatibilidad: ciertas aplicaciones empresariales modernas, software que usa APIs recientes de Windows o dependencias muy concretas pueden funcionar mal o directamente no arrancar.

En cambio, Winpodx lanza un Windows completo (aunque optimizado) dentro de un contenedor, lo que le permite alcanzar una compatibilidad mucho más cercana al 100 %, ya que el software cree estar corriendo en un entorno genuino de Microsoft. Eso reduce mucho las sorpresas a la hora de usar suites corporativas pesadas o herramientas muy específicas.

Máquinas virtuales clásicas: compatibilidad total, integración pobre

Soluciones como VirtualBox, VMware o Parallels ofrecen compatibilidad casi absoluta, pero lo hacen a costa de un overhead grande: la VM consume memoria de forma constante, se siente como “otro equipo dentro de tu equipo” y la integración con el escritorio host suele limitarse a compartir carpetas, portapapeles y poco más.

Winpodx toma muchas de las ventajas de la VM (compatibilidad, aislamiento, facilidad para cumplir requisitos de licencia) y las combina con una integración visual muy superior: cada app es una ventana del host, las asociaciones de archivo funcionan en ambos sentidos y el contenedor se suspende automáticamente cuando no se usa, reduciendo el impacto en rendimiento cuando estás trabajando solo con apps de Linux.

WSL vs Winpodx: dos caras de la misma moneda

WSL (Windows Subsystem for Linux) resolvió el problema inverso: correr apps de Linux dentro de Windows con un híbrido entre máquina virtual ligera (en WSL2) y subsistema de compatibilidad. Permite ejecutar tanto herramientas de consola como aplicaciones gráficas (vía WSLg), con una integración bastante razonable y soporte de GPU en muchos casos.

Winpodx, por su parte, es como la pieza que faltaba en el lado Linux: hace el camino contrario, trayendo aplicaciones de Windows al escritorio Linux. Mientras WSL2 se apoya en una VM completa muy afinada, Winpodx apuesta por contenedores (especialmente Podman), lo que se traduce en un consumo de recursos menor y en una gestión más alineada con el mundo cloud-native. La contrapartida es que, a día de hoy, Winpodx no ofrece un soporte de passthrough de GPU “plug and play” equivalente al de WSL2.

Limitaciones, rendimiento y consideraciones de licenciamiento

Pese a todas sus virtudes, Winpodx no es una bala de plata que sirva para absolutamente todo. Conviene tener claras sus limitaciones antes de adoptarlo como pieza central en un flujo de trabajo crítico.

Rendimiento gráfico y GPU passthrough

El principal punto débil ahora mismo es el soporte limitado para aceleración gráfica nativa. Winpodx puede ejecutar sin problema suites de productividad (Microsoft Office), editores de texto avanzados (Notepad++), navegadores, herramientas de desarrollo como Visual Studio o SQL Server Management Studio, e incluso Photoshop en uso básico, pero no está pensado para edición de vídeo 4K pesada ni para gaming moderno.

Si necesitas sacar partido de la GPU dentro del contenedor de Windows, toca configurar a mano passthrough de GPU con VFIO o recurrir a máquinas virtuales basadas en KVM, que están más maduras para ese tipo de escenarios. También se pueden considerar alternativas como VirtualBox con extensiones de invitado para usuarios que no quieren lidiar con detalles de bajo nivel.

Licenciamiento de Windows y soporte

Aunque Winpodx sea open source y gratuito, no elimina la necesidad de disponer de licencias válidas de Windows. El contenedor ejecuta una copia real del sistema operativo de Microsoft, así que debes cumplir con los términos de licenciamiento correspondientes, igual que si montaras una VM tradicional.

Además, al tratarse de un proyecto relativamente joven con comunidad emergente, no hay SLA empresarial ni soporte comercial garantizado salvo que algún tercero lo ofrezca de forma independiente. Para equipos que dependen de un soporte 24/7 o que trabajan en entornos extremadamente regulados, esto es algo a valorar con calma.

Curva de aprendizaje y madurez del proyecto

Aunque la promesa de Winpodx es “casi sin configuración”, requiere cierta familiaridad con contenedores (Docker/Podman) y conceptos como RDP, especialmente si quieres salirte del camino feliz y empezar a hacer ajustes finos. Los usuarios que ya mueven servicios en contenedores no deberían tener grandes problemas, pero alguien procedente solo de entornos de escritorio puede necesitar algo de tiempo para sentirse cómodo.

El proyecto está en desarrollo activo, con versiones recientes como la 0.5.0 que introducen funciones potentes como reverse-open. Esto significa que aún hay bordes ásperos y cambios frecuentes, aunque la base ya es lo bastante madura como para que las pruebas de usuarios reales sean el feedback más valioso para el autor.

Casos de uso: para quién tiene sentido Winpodx

Winpodx encaja de manera especialmente buena en startups, equipos técnicos y profesionales que han apostado por Linux pero siguen atados a software de Windows sin alternativa real. Algunos escenarios claros donde brilla:

• Desarrolladores que trabajan en Linux pero necesitan puntualmente herramientas como Visual Studio, SSMS, Office o software propietario de clientes solo para Windows.
• Startups con infraestructura mayoritariamente Linux que han heredado procesos o aplicaciones Windows críticas (ERP, aplicaciones contables, herramientas internas).
• Equipos de QA y testing multiplataforma que tienen que comprobar el comportamiento de sus productos tanto en Linux como en Windows sin cambiar de máquina.
• Entornos con fuertes restricciones de red o sin conexión (air-gapped), ya que Winpodx contempla rutas de instalación offline con parámetros como –source y –image-tar.

En todos estos casos, la capacidad de tratar el contenedor como un servicio más (monitorizado, con logs, con health checks) y la integración fina con el escritorio reducen mucha fricción operativa frente a mantener máquinas Windows físicas o VMs aisladas que solo se usan para “esa app rara”.

Para plantearte seriamente su adopción conviene, eso sí, seguir algunos pasos: revisar tu stack de aplicaciones para ver qué software Windows no tiene sustituto nativo, montar una instancia de prueba con un conjunto concreto de apps críticas, y por último calcular el coste total de propiedad frente a seguir manteniendo hardware o VMs dedicadas. En equipos pequeños la diferencia puede ser considerable.

En conjunto, Winpodx se ha consolidado como una de las propuestas más interesantes para unir los mundos Linux y Windows sin renunciar a la comodidad del escritorio. Ofrece un equilibrio muy atractivo entre compatibilidad, rendimiento razonable y automatización, con extras como el reverse-open y la auto-descarga de iconos que lo acercan a la experiencia que muchos valoran en WSL, pero esta vez desde el lado del pingüino. Si tu día a día mezcla herramientas de ambos ecosistemas y te cansa vivir entre arranques dobles o máquinas virtuales pesadas, darle una oportunidad a Winpodx puede ahorrarte bastante tiempo y algún que otro quebradero de cabeza.

from Linux Adictos https://ift.tt/ajqAD5z
via IFTTT

En las últimas semanas el mundo Linux se ha visto sacudido por una nueva vulnerabilidad que, para muchos administradores, ha sido la gota que colma el vaso en una racha de fallos críticos en el kernel. Hablamos de Fragnesia, un exploit de escalada local de privilegios que se suma a la familia de fallos conocidos como Copy Fail y Dirty Frag, y que permite a cualquier usuario sin privilegios conseguir root con un único comando en sistemas vulnerables.

Tras Copy Fail y Dirty Frag, Fragnesia llega en un contexto de auténtica “fatiga de parches”: actualizaciones urgentes, reinicios encadenados y mitigaciones de emergencia. Sin embargo, dejarlo pasar no es una opción. El fallo afecta a múltiples distribuciones Linux y versiones de kernel, y ya existe una prueba de concepto pública totalmente funcional. En este artículo vamos a desgranar qué es Fragnesia, cómo funciona el ataque, qué distribuciones están afectadas, qué parches y mitigaciones existen y cómo comprobar si tu sistema está protegido.

Qué es Fragnesia y por qué se relaciona con Dirty Frag y Copy Fail

Fragnesia es un nuevo exploit de escalada local de privilegios (LPE) en el kernel de Linux que se encuadra en la misma familia de vulnerabilidades que Copy Fail (CVE-2026-31431) y Dirty Frag (también conocido como Copy Fail 2, CVE-2026-43284). Comparte con ellas la idea base: abusar de fallos lógicos en la pila de red y el manejo de memoria del kernel para obtener una primitiva de escritura en memoria que permita modificar archivos teóricamente de solo lectura y acabar ejecutando código como root.

El fallo ha sido bautizado como Fragnesia y rastreado como CVE-2026-46300, con una puntuación CVSS de 7,8. La vulnerabilidad fue descubierta por William Bowling, del equipo de seguridad V12. Poco después, Sam James anunció el problema en la lista de correo de OSS Security, aclarando que no se trataba de un simple reanálisis de Dirty Frag, sino de un bug distinto en la misma superficie funcional del kernel.

En términos prácticos, Fragnesia es el tercer fallo crítico de este tipo en apenas dos semanas: Copy Fail, Dirty Frag y ahora Fragnesia. Los tres se aprovechan de problemas en el manejo de datos en el kernel para corromper la caché de páginas (page cache) de archivos críticos como /usr/bin/su, pero Fragnesia lo logra a través de otra ruta: el subsistema ESP-in-TCP de XFRM.

Detalles técnicos: el subsistema XFRM ESP-in-TCP y el fallo de lógica

El núcleo de Fragnesia reside en un fallo de lógica en el subsistema Linux XFRM ESP-in-TCP, concretamente en la ruta del ULP (Upper Layer Protocol) denominada espintcp. XFRM es el marco del kernel encargado, entre otras cosas, de procesar tráfico IPsec, y ESP (Encapsulating Security Payload) es el protocolo que proporciona confidencialidad y autenticidad mediante cifrado (por ejemplo, AES-GCM), como ocurrió con una vulnerabilidad en el protocolo de red CAN BCM.

El ataque se basa en una situación muy concreta del kernel: cuando un socket TCP pasa a modo ESP-in-TCP después de que se hayan introducido en su cola de recepción páginas de fichero mediante llamadas como splice(2) o sendfile(2). En lugar de tratar esos datos como simples páginas provenientes de un archivo, el kernel los interpreta como si fueran texto cifrado ESP y aplica la “desencriptación” sobre ellas, modificando así las páginas de la caché de forma in situ.

Como consecuencia de este error, el kernel inyecta el flujo de claves de AES-GCM sobre páginas de la caché correspondientes a archivos de solo lectura, lo que se traduce en escrituras de bytes arbitrarias en la page cache. Controlando el IV (nonce) y otros parámetros, un usuario sin privilegios puede dirigir estas escrituras con mucha precisión. El resultado es una primitiva de escritura determinista que permite alterar una cantidad controlada de bytes de cualquier archivo legible, pese a que el sistema de ficheros lo marque como inmutable o de solo lectura.

La prueba de concepto pública se centra en modificar el binario /usr/bin/su en la caché de páginas. Inyecta un stub ELF de 192 bytes (posicionalmente independiente) en la copia en memoria de ese binario. A partir de ese momento, la siguiente vez que se ejecute su, se ejecutará el stub con privilegios de root, proporcionando una escalada instantánea sin necesidad de carreras de condiciones ni de otros trucos adicionales.

Mitigaciones temporales: cómo protegerte si no puedes reiniciar

Aunque lo recomendable es instalar un kernel parcheado y reiniciar lo antes posible, se han descrito mitigaciones temporales efectivas para quienes no puedan permitirse un reinicio inmediato. La buena noticia es que, dado que Fragnesia explota los mismos módulos base (esp4, esp6 y opcionalmente rxrpc) que Dirty Frag, la mitigación propuesta para este último sirve igualmente para Fragnesia.

La técnica consiste en bloquear la carga de los módulos vulnerables mediante la configuración de modprobe y, si estuvieran ya cargados, descargarlos de memoria. Se hace escribiendo una regla en /etc/modprobe.d/ que sustituye la carga de esos módulos por comandos inofensivos (como /bin/false). Después se invoca a rmmod sobre ellos, ignorando silenciosamente los errores si no están presentes.

En distribuciones como CloudLinux, el comando propuesto para Dirty Frag (que vale igual para Fragnesia) genera un archivo dirtyfrag.conf con reglas para esp4, esp6 y rxrpc, y a la vez intenta descargar los módulos activos. Si ya aplicaste esta mitigación por Dirty Frag, no tienes que hacer nada más para Fragnesia hasta que instales el kernel corregido, porque la superficie de ataque queda igualmente neutralizada.

Es importante tener en cuenta la compatibilidad: esp4 y esp6 son los transform del kernel para IPsec. Deshabilitarlos rompe los túneles IPsec que dependan de la ruta de datos del kernel (por ejemplo, strongSwan o Libreswan). La recomendación es no usar esta mitigación en hosts que terminen o enruten tráfico IPsec crítico. El módulo rxrpc es el transporte AF_RXRPC, usado casi exclusivamente por clientes AFS, y rara vez está presente en servidores web u otros escenarios generalistas.

Restaurar la caché de páginas tras aplicar la mitigación

Otro punto a menudo pasado por alto es que el exploit, al funcionar, puede dejar en memoria copias modificadas de binarios legítimos en la page cache. El ejemplo más típico es /usr/bin/su, pero podrían verse afectados otros binarios privilegiados si el atacante decide cambiar de objetivo.

Por ello, algunos avisos recomiendan que, tras aplicar la mitigación de blacklist de módulos, se proceda a vaciar la caché de páginas del sistema para forzar una recarga limpia desde disco. Esto se puede lograr escribiendo en /proc/sys/vm/drop_caches un valor que indique al kernel que libere cache page y dentries/inodes. Esta operación solo elimina páginas limpias, por lo que es segura en sistemas en producción, aunque puede generar un aumento puntual de E/S al disco cuando los binarios y datos se vuelvan a leer.

La idea es sencilla: si una instancia de Fragnesia ya hubiera sido ejecutada antes de mitigar, las páginas corrompidas se descartan y se volverá a usar la versión en disco sin alterar. Combinado con la blacklist de módulos, este paso reduce el riesgo de que una posible modificación residual en la cache siga siendo explotable o provoque comportamientos erráticos en el sistema.

Estado de los parches y recomendaciones de los proveedores

La mayoría de los grandes actores del ecosistema Linux han respondido de forma rápida al descubrimiento de Fragnesia. Distribuciones como AlmaLinux y CloudLinux han publicado o están finalizando kernels parcheados, mientras que Red Hat ha indicado que está evaluando hasta qué punto las mitigaciones existentes para vulnerabilidades previas cubren también CVE-2026-46300.

Varios proveedores de seguridad, como empresas asociadas a Google y Microsoft, han publicado análisis explicando que la vulnerabilidad permite a atacantes locales sin privilegios modificar contenidos de archivos de solo lectura en la caché de páginas y escalar a root mediante corrupción determinista de memoria. Wiz, por ejemplo, destaca que AppArmor y las restricciones sobre user namespaces sin privilegios pueden mitigar parcialmente el impacto al requerir técnicas adicionales para explotar con éxito el bug en algunos entornos.

Microsoft, por su parte, señala que no se ha observado explotación activa en la naturaleza en el momento de su comunicado, pero aun así insta a aplicar el parche tan pronto como esté disponible, utilizando las herramientas de actualización habituales. Cuando no sea posible parchear de inmediato, recomiendan aplicar las mismas mitigaciones propuestas para Dirty Frag: desactivar esp4, esp6 y funcionalidad relacionada con IPsec/XFRM no imprescindible, endurecer el acceso local interactivo y reforzar el monitoreo de actividades inusuales de escalada de privilegios.

Contexto de amenazas: mercado de exploits y fatiga de parches

El descubrimiento de Fragnesia se produce en un contexto en el que la explotación de fallos de escalada local en Linux gana valor en el mercado negro. Informes recientes describen a un actor, bajo el alias “berz0k”, ofreciendo un zero-day de escalada local en Linux por 170.000 dólares, supuestamente funcional en múltiples distribuciones. Según ThreatMon, el vendedor afirma que la vulnerabilidad es de tipo TOCTOU (Time-of-Check Time-of-Use), permite una escalada estable sin provocar cuelgues y utiliza un payload en forma de biblioteca compartida (.so) desplegada en /tmp.

Todo esto alimenta la sensación de saturación y cansancio que muchos administradores expresan: “otra vulnerabilidad de la misma categoría que Dirty Frag”, “ocho más como esta y ya desconecto”, comentan algunos de forma medio en broma, medio en serio. La realidad es que la sucesión de Copy Fail, Dirty Frag y Fragnesia está obligando a los equipos de sistemas a replantearse su estrategia de actualización del kernel, especialmente en entornos donde los reinicios frecuentes son muy costosos.

En este paisaje, soluciones de livepatching como KernelCare o mecanismos similares cobran protagonismo como alternativa para aplicar correcciones críticas sin interrumpir servicios, mientras que las distribuciones se ven presionadas para acortar al máximo los tiempos entre el descubrimiento, la publicación del fix upstream y la disponibilidad del paquete parcheado en repositorios estables.

En última instancia, Fragnesia se ha convertido en un caso de estudio de cómo una pequeña pieza de lógica en un subsistema especializado como XFRM ESP-in-TCP puede tener consecuencias devastadoras cuando se combina con mecanismos de caché de páginas y binarios privilegiados. Mantenerse al tanto de avisos de seguridad, listas de correo, blogs de distribuciones y canales de comunicación como Mattermost o X (antes Twitter) es clave para reaccionar con rapidez y minimizar la ventana de exposición.

La amenaza que representa Fragnesia no radica solo en su capacidad de dar root con un comando, sino en que demuestra hasta qué punto los entornos Linux modernos dependen de una cadena de confianza compleja que va desde el código del kernel hasta las herramientas de actualización y las políticas de endurecimiento. Estar protegido pasa por combinar parches oficiales, mitigaciones bien entendidas, soluciones de livepatch donde tenga sentido y una política clara de control de acceso local y monitorización, de forma que un fallo de este tipo no se convierta en el punto único de fallo para toda la infraestructura.

from Linux Adictos https://ift.tt/bkU2aul
via IFTTT