La capacidad de poder ofrecer compilaciones reproducibles en Linux es una marca de transparencia y seguridad en la que actualmente diversas distribuciones se encuentran trabajando y que otras ya ofrecen.

La importancia de ello radica en que esto permite tanto a desarrolladores, investigadores como a usuarios verificar que el binario distribuido se ha creado correctamente a partir del código fuente proporcionado y no ha sido alterado.

Consultado un poco la documentación de Linux, podemos entender que:

Generalmente es deseable que la construcción del mismo código fuente con el mismo conjunto de herramientas sea reproducible, es decir, que el resultado sea siempre exactamente el mismo. Esto hace posible verificar que la infraestructura de construcción para una distribución binaria o un sistema integrado no haya sido subvertida. Esto también puede facilitar la verificación de que un cambio de fuente o herramienta no supone ninguna diferencia en los archivos binarios resultantes

Y en el caso Linux y de manera general en todo el software de código abierto, las compilaciones reproducibles son esenciales para garantizar que la comunidad pueda verificar y auditar el software de manera, además de que esto permite poder detectar cambios mal intencionados.

openSUSE Factory ya ofrece compilaciones reproducibles «bit a bit»

La razón de mencionar esto, es que el proyecto openSUSE ha introducido el soporte para compilaciones reproducibles «bit a bit» en su repositorio openSUSE Factory, que es la base para la distribución openSUSE Tumbleweed.

Esta actualización permite garantizar que los archivos binarios distribuidos en los paquetes sean generados de manera consistente a partir del código fuente proporcionado, sin incluir cambios ocultos y como mencionamos, el beneficio de realizar esto, es que cualquier usuario puede verificar por sí mismo que las compilaciones propuestas coinciden exactamente con las compilaciones generadas desde los códigos fuente.

Un ejemplo reciente es que las compilaciones reproducibles permiten la creación de pruebas, simplemente reconstruyendo y comparando el resultado, de que una compilación de GCC cuya fuente se extrajo con un xz comprometido no estaba comprometida; Este proceso se logró sin necesidad de realizar ingeniería inversa sobre cómo se produjo el compromiso. De manera similar, se informó que las compilaciones reproducibles eran útiles durante las investigaciones del compromiso xz

Las compilaciones reproducibles se logran teniendo en cuenta detalles como la exactitud en las dependencias, el uso de las mismas versiones y configuraciones de las herramientas de compilación, un conjunto idéntico de opciones y configuraciones predeterminadas, la preservación del orden de los archivos en la compilación (mediante métodos de clasificación consistentes), y la desactivación de la adición de información no permanente por parte del compilador, como valores aleatorios, referencias de rutas de archivos, y detalles de fecha y hora de la compilación

La capacidad de verificar un binario ofrece una capa adicional de seguridad al no depender únicamente de la confianza en la infraestructura del compilador. Esto es crucial porque comprometer el compilador o las herramientas de compilación podría conducir a la inserción de elementos maliciosos o cambios ocultos en los binarios resultantes.

Por ejemplo, los desarrolladores de openSUSE utilizaron compilaciones repetibles para garantizar la integridad de los binarios después del famoso incidente del backdoor detectado en el paquete xz. En este caso, la biblioteca liblzma comprometida, utilizada para descomprimir archivos con código GCC, podría haber introducido cambios maliciosos en el código GCC, lo que a su vez podría afectar a las aplicaciones ensambladas.

Es importante tener en cuenta que el repositorio Factory no está destinado a usuarios finales, sino principalmente a desarrolladores de distribuciones. Esto se debe a que su estabilidad no está garantizada en todo momento.

Los paquetes agregados a Factory pasan por pruebas automatizadas utilizando openQA. Una vez que estas pruebas se completan y se verifica la consistencia del estado de dependencia, el contenido del repositorio se sincroniza con los espejos varias veces por semana. El resultado final de este proceso se publica como openSUSE Tumbleweed, que es la distribución estable y confiable que los usuarios finales pueden utilizar con confianza.

Si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

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

Si se explotan, estas fallas pueden permitir a los atacantes obtener acceso no autorizado a información confidencial o, en general, causar problemas

Hace ya varios días se dio a conocer la noticia de que fue detectada una vulnerabilidad en Flatpak (el sistema para construir, distribuir y ejecutar entornos aislados de aplicaciones de escritorio en Linux). Catalogada bajo CVE-2024-32462, junto con la clasificación CWE-88, la vulnerabilidad descubierta permitía escapar del sandbox a través de RequestBackground.

Esta vulnerabilidad afecta a ciertas versiones específicas de Flatpak, y su impacto puede ser grave, ya que una aplicacion especialmente diseñada podría ejecutar código arbitrario fuera del sandbox, comprometiendo la información del usuario.

Sobre la vulnerabilidad CVE-2024-32462

Se menciona que la vulnerabilidad permite que una aplicación maliciosa o comprometida distribuida mediante un formato de paquete flatpak eluda el modo de aislamiento de la zona de pruebas y acceda a los archivos del sistema principal. Este problema se manifiesta solo en paquetes que utilizan los portales de Freedesktop (xdg-desktop-portal), empleados para facilitar el acceso a recursos en el entorno del usuario desde aplicaciones aisladas.

Es posible pasar una interfaz arbitraria commandlinea la interfaz del portal org.freedesktop.portal.Background.RequestBackgrounddesde una aplicación Flatpak. Normalmente esto es seguro, porque sólo puede especificar un comando que existe dentro del entorno sandbox; pero cuando un objeto elaborado commandlinese convierte en –commandargumentos and, la aplicación podría lograr el mismo efecto de pasar argumentos directamente a bwrapy, por lo tanto, lograr un escape de zona protegida.

La solución es que Flatpak use el –argumento to bwrap, lo que hace que detenga las opciones de procesamiento, antes de agregar el comando especificado por el atacante. El –argumento ha sido respaldado desde bubblewrap 0.3.0, y todas las versiones compatibles de Flatpak ya requieren al menos esa versión de bubblewrap.

La explotación de esta vulnerabilidad permite a una aplicación en un entorno aislado utilizar la interfaz xdg-desktop-portal para crear un archivo «.desktop» con un comando que inicia la aplicación desde flatpak, permitiendo así el acceso a los archivos en el sistema principal.

La esencia de la vulnerabilidad que permite evadir el entorno aislado reside el argumento –command de flatpak run, el cual esperaba recibir un comando para ejecutar en la aplicación Flatpak especificada, junto con algunos argumentos opcionales. Al manipular el parámetro «–command«, que se emplea para pasar el nombre del programa, era posible pasar un nombre de opción, como por ejemplo –bind, y esto era interpretado erróneamente como una opción de bwrap para ejecutar el programa especificado dentro del paquete, en un entorno aislado.

Un ejemplo práctico de ello que se menciona, es para ejecutar la utilidad ls en un entorno de paquetes aislado, se utiliza algo similar a esto:

"flatpak run --command=ls org.gnome.gedit"

La cual ejecutará:

"bwrap ...lots of stuff... --bind / /host ls -l /host".

En este caso, el nombre «–bind» no se considerará como el nombre de la aplicación a ejecutar, sino como una opción de bwrap.

Como tal, la vulnerabilidad radica en el hecho de que si el nombre del programa comienza con los caracteres «–«, la utilidad bwrap lo interpretará como su propia opción. Originalmente, enviar comandos de esta manera no se consideraba peligroso, ya que se ejecutarían en un entorno aislado del paquete. Sin embargo, no se tuvo en cuenta que los comandos que comienzan con «–» serán interpretados como opciones por la utilidad bwrap. Como resultado, la interfaz xdg-desktop-portal se puede aprovechar para crear un archivo «.desktop» con un comando que explote esta vulnerabilidad.

El argumento —  ha sido compatible desde bubblewrap 0.3.0, y todas las versiones compatibles de Flatpak ya requieren al menos esa versión de bubblewrap. Se menciona que una de las soluciones es que la versión 1.18.4 de xdg-desktop-portal ya no permita que las aplicaciones Flatpak creen nuevos archivos .desktop para los comandos que se inician con -.

Finalmente cabe mencionar que la vulnerabilidad ha sido corregida en las versiones parcheadas de Flatpak 1.15.8, 1.14.6, 1.12.9 y 1.10.9. Asimismo, se ha propuesto una solución de seguridad en las versiones 1.16.1 y 1.18.4 de xdg-desktop-portal.

Puedes consultar la versión de Flatpak que tienes ejecutando el siguiente comando:

flatpak --version

En dado caso de estar sobre una versión vulnerable o si quieres actualizar tu versión de Flatpak, basta con ejecutar alguno de los siguientes comando:

Ubuntu/Debian y derivados:

sudo apt upgrade flatpak

RHEL/Fedora  y derivados:

sudo dnf upgrade flatpak

Arch Linux y derivados:

sudo pacman -Syu flatpak

Si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

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

Después de un período de prueba de 6 meses, al 1 de abril de 2024, los desarrolladores del entorno de escritorio XFCE dieron conocer, mediante una publicación de blog, la decisión de trasladar los canales oficiales de comunicación del proyecto XFCE de IRC a Matrix.

Los desarrolladores mencionan que la principal razón detrás de esta migración es principalmente a la finalización del soporte para la integración de canales IRC en Matrix en la red IRC Libera.Chat, ya que muchos desarrolladores usaban Matrix para acceder a los canales de IRC a través de estos.

El cierre se debe a la decisión de tomar acción respecto al puente de Element Matrix Services (EMS) surgió por diversas preocupaciones de estabilidad, seguridad y privacidad, lo que culminó en la solicitud de desactivar la función de portal de EMS.

Otro de los factores que llevo a Libera.Chat a tomar la decisión fue debido a la carga de abusos, incluyendo oleadas de bots, filtraciones de privacidad y vulnerabilidades de seguridad, generó una tensión significativa en los recursos de Libera y la dificultad para abordar estos problemas con EMS.

Los desarrolladores de XFCE mencionaron que al perder el soporte, se fragmentó la comunicación entre usuarios que permanecieron en IRC y aquellos que se mudaron a canales Matrix independientes y con la finalidad de mantener una plataforma de comunicación unificada, se optó por transferir oficialmente los canales a la plataforma Matrix.

Además, la disminución de la popularidad de IRC se debe a varios factores, como la falta de familiaridad para los nuevos usuarios y la obsolescencia del protocolo en comparación con las necesidades modernas de comunicación.

Y es que Matrix ofrece una gran cantidad de ventajas al ser una plataforma abierta y descentralizada, lo cual es un ganar-ganar tanto para el proyecto como para la comunidad. Entre las ventajas de Matrix sobre IRC que contribuyeron a esta elección, se destacan las siguientes:

• Facilidad de uso: Matrix proporciona una experiencia de uso más amigable en comparación con IRC, lo que puede reducir la barrera de entrada para nuevos usuarios.
• Cifrado de extremo a extremo: Matrix ofrece cifrado de extremo a extremo de forma predeterminada, lo que garantiza la privacidad y seguridad de las conversaciones.
• Sincronización de mensajes: Los canales de Matrix retienen los mensajes que llegan mientras un usuario está desconectado, evitando la pérdida de información y fomentando una comunicación más fluida.
• Plataforma abierta y descentralizada: Matrix es una plataforma abierta y no depende de servidores centralizados, lo que la hace más resistente a fallos y censura.
• Multi-dispositivo: El historial de chat se sincroniza en múltiples dispositivos de forma predeterminada en Matrix, eliminando la necesidad de configuraciones complejas.
• Al acceder a canales IRC a través del puente Matrix, no es necesario administrar un Bouncer IRC . Los canales Bridged Matrix retienen los mensajes que llegan mientras usted no está conectado.

Se menciona que aunque los canales IRC anteriores siguen disponibles, ahora el principal punto de atención es la promoción de los canales basados en Matrix como el método oficial de comunicación interactiva en la documentación y el sitio web del proyecto.

Por ejemplo, para soporte técnico y discusiones generales, se alienta a usar #xfce:matrix.org en lugar del antiguo canal IRC #xfce en la red libera.chat. De manera similar, para debates relacionados con el desarrollo, se sugiere utilizar #xfce-dev:matrix.org en lugar de #xfce-dev en IRC, y para rastrear la actividad en GitLab, se recomienda #xfce-commits:matrix.org en lugar de #xfce-commits en IRC

Finalmente, cabe mencionar que Matrix no es el único canal de comunicación que tiene el proyecto XFCE, ya que también se ofrece a los usuarios la posibilidad de contribuir, participar o enviar sus dudas en el foro de Xfce o en la lista de correo xfce. De igual forma, si tienes dudas sobre como informarte en el proceso de desarrollo del entorno, puedes consultar su wiki en el siguiente enlace.

Si estás interesado en poder conocer más al respecto, puedes consultar los detalles en él, siguiente enlace.

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

Niri es un compositor de Wayland con mosaicos desplazables

Niri, el compositor Wayland escrito en Rus ha llegado a su versión «Niri 0.1.5», en la cual el principal foco de atención fue el trabajo en las mejoras de soporte en animaciones, mejoras en el manejo de comunicación entre procesos y correcciones de errores importantes.

Para quienes desconocen de Niri deben saber que este es un compositor de Wayland inspirado en la extensión PaperWM de Gnome y adoptando un método de diseño en mosaico donde las ventanas se agrupan en una cinta que se desplaza infinitamente en la pantalla. Cada vez que se abre una nueva ventana, la cinta se expande, mientras que las ventanas previamente agregadas mantienen su tamaño.

Niri ofrece la capacidad de ejecutar aplicaciones X11 mediante el servidor Xwayland DDX. También cuenta con una interfaz integrada para tomar capturas de pantalla y grabar screencasts, con opciones para excluir ventanas individuales de las grabaciones, protegiendo así información confidencial.

¿Qué hay de nuevo en Niri 0.1.5?

En esta nueva versión que se presenta de Niri, como se mencionó al inicio, la principal novedad son las nuevas animaciones “spring animations” donde los valores y duraciones están más restringidos en casos específicos, asegurando que las ventanas no se vuelvan transparentes durante los rebotes. El uso de slowdown ahora escala la velocidad del gesto del touchpad, garantizando una animación más fluida.

Otro de los cambios que se realizó en las animaciones fue en el movimiento, redimensionamiento y cierre de ventanas, esto con la finalidad de implementar ajustes para que puedan funcionar sin problemas con ventanas bloqueadas en las grabaciones de pantalla, y los usuarios tienen la opción de deshabilitarlas o configurarlas individualmente.

Además de ello, no solo las animaciones fueron las que recibieron mejoras, ya que en Niri 0.1.5 se integró el soporte básico de tasa de refresco variable (VRR) que tiene como objetivo mejorar la suavidad de las animaciones en pantallas compatibles. Para ello, «niri msg outputs» ahora muestra si VRR es compatible y puede ser habilitado configurando el parámetro variable-refresh-rate en la configuración de salida.

Niri 0.1.5 también presenta diversas mejoras en la comunicación entre procesos (IPC) como la adición de «niri msg version» para mostrar la versión de Niri y la versión de la interfaz de línea de comandos (CLI de Niri).

También se han corregido algunos problemas menores, como el manejo del comportamiento de DRM leasing, la ocultación del cursor del ratón al interactuar con la pantalla táctil y la restauración de la posición de vista anterior al deshacer el modo de pantalla completa.

Se han realizado mejoras adicionales, como la restauración de la posición de vista anterior al deshacer el modo de pantalla completa, la ocultación del cursor del ratón al interactuar con la pantalla táctil y mejoras en el comportamiento del DRM leasing para prevenir fallas y manejar mejor los hotplugs.

Además de las nuevas características, se han implementado diversas correcciones y mejoras adicionales, las cuales incluyen:

• La adición de una curva de aceleración ease-out-quad,
• La corrección de problemas con el comportamiento de un gesto de touchpad horizontal
• Adición de un ejemplo de enlaces para deshabilitar el micrófono en la configuración predeterminada. También se han realizado ajustes en la gestión de SIGPIPE en niri msg

Finalmente, si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

¿Como instalar Niri en Linux?

Para los interesados en el proyecto, deben saber que se ofrecen paquetes compilados para Fedora, NixOS, Arch Linux y FreeBSD.

Para el caso de Fedora o derivados, basta con teclear:

dnf copr enable yalter/niri

Mientras que para Arch Linux, el comando es el siguiente:

sudo pacman -S niri

Para el caso de otras distribuciones, puedes consultar la documentación en el siguiente enlace, donde también podrás conocer un poco más sobre la personalización qué se realiza a través de un archivo de configuración que permite ajustar parámetros como el ancho del marco, el relleno, los modos de salida y el tamaño de las ventanas, todo sin necesidad de reiniciar el servidor compuesto.

from Linux Adictos https://ift.tt/4Q9LHoV
via IFTTT