Se ha publicado una nueva versión estable de la herramienta Flatpak 1.14, que proporciona un sistema para construir paquetes autosuficientes, independientes de distribuciones específicas de Linux y que se ejecutan en un contenedor especial que aísla la aplicación del resto del sistema. El soporte para la ejecución de paquetes Flatpak está garantizado para Arch Linux, CentOS, Debian, Fedora, Gentoo, Mageia, Linux Mint, Alt Linux y Ubuntu. Los paquetes con Flatpak están incluidos en el repositorio de Fedora y son compatibles con la aplicación de gestión de software integrada de GNOME.
Novedades clave en la versión Flatpak 1.14:
- Se ha habilitado la creación de un directorio para archivos en estado (.local/state) y la asignación de la variable de entorno XDG_STATE_HOME que apunta a este directorio.
- Se han añadido comprobaciones condicionales del tipo “have-kernel-module-nombre” para determinar la existencia de módulos del kernel (un equivalente universal a la comprobación anterior have-intel-gpu, donde ahora se puede usar la expresión “have-kernel-module-i915”).
- Se ha implementado el comando “flatpak document-unexport —doc-id=…”.
- Se ha garantizado la exportación de metadatos de Appstream para su uso en el entorno principal.
- Se han añadido reglas de autocompletado de comandos flatpak para la shell Fish.
- Se ha permitido el acceso en red a los servicios X11 y PulseAudio (con la adición de configuraciones correspondientes).
- La rama principal en el repositorio de Git ha sido renombrada de “master” a “main”, ya que la palabra “master” se considera políticamente incorrecta en estos tiempos.
- Se ha garantizado la reescritura de scripts de inicio en caso de que se renombre la aplicación.
- Se han añadido opciones “—include-sdk” y “—include-debug” al comando install para la instalación del SDK y de los archivos debuginfo.
- Se ha añadido soporte para el parámetro “DeploySideloadCollectionID” en los archivos flatpakref y flatpakrepo, donde al instalar, el identificador de la colección se asignará durante la adición del repositorio remoto y no después de descargar metadatos.
- Se ha permitido la creación de entornos sandbox anidados para los controladores en sesiones con nombres MPRIS (Media Player Remote Interfacing Specification) distintos.
- Las utilidades de línea de comandos han proporcionado información sobre el uso de extensiones de runtime obsoletas.
- En el comando uninstall se ha implementado una solicitud de confirmación antes de eliminar runtime o extensiones de runtime que todavía están en uso.
- Se ha añadido soporte para la opción “—socket=gpg-agent” en comandos como “flatpak run”.
- Se ha solucionado una vulnerabilidad en libostree que podría permitir a un usuario eliminar archivos arbitrarios en el sistema manipulando el manejador flatpak-system-helper (enviando una solicitud de eliminación con un nombre de rama especialmente formado). El problema solo se presenta en versiones antiguas de Flatpak y libostree lanzadas antes de 2018 (< 0.10.2) y no afecta a las versiones actuales.
Recordemos que Flatpak permite a los desarrolladores de aplicaciones simplificar la distribución de sus programas que no están en los repositorios estándar de las distribuciones, mediante la preparación de un único contenedor universal sin necesidad de crear compilaciones individuales para cada distribución. A los usuarios preocupados por la seguridad, Flatpak les permite ejecutar aplicaciones dudosas en un contenedor, brindando acceso solo a funciones de red y a los archivos del usuario relacionados con la aplicación. A los usuarios interesados en las novedades, Flatpak les permite instalar las versiones de prueba y estables más recientes de aplicaciones sin necesidad de realizar cambios en el sistema. Por ejemplo, los paquetes Flatpak se compilan para LibreOffice, Midori, GIMP, Inkscape, Kdenlive, Steam, 0 A.D., Visual Studio Code, VLC, Slack, Skype, Telegram Desktop, Android Studio, etc.
Para reducir el tamaño del paquete, incluye solo las dependencias específicas de la aplicación, mientras que las bibliotecas gráficas y del sistema básicas (GTK, Qt, bibliotecas GNOME y KDE, etc.) se estructuran como entornos de ejecución modulares. La principal diferencia entre Flatpak y Snap es que Snap utiliza componentes del entorno del sistema principal y aislamiento basado en la filtración de llamadas al sistema, mientras que Flatpak crea un contenedor separado del sistema y opera con grandes conjuntos de runtime, proporcionando como dependencias no paquetes, sino entornos de sistema genéricos (por ejemplo, todas las bibliotecas necesarias para el funcionamiento de programas GNOME o KDE).
Además del entorno de sistema estándar (runtime), que se instala a través de un repositorio especial, se proporcionan dependencias adicionales (bundle) necesarias para el funcionamiento de la aplicación. En total, el runtime y el bundle conforman el contenido del contenedor, dado que el runtime se instala por separado y se vincula a varios contenedores a la vez, lo que evita la duplicación de archivos sistemáticos comunes a los contenedores. En un sistema pueden instalarse varios runtimes diferentes (GNOME, KDE) o varias versiones de un mismo runtime (GNOME 3.40, GNOME 3.42). El contenedor de la aplicación como dependencia utiliza la vinculación solo a un runtime específico, sin tener en cuenta los paquetes individuales que componen el runtime. Todos los elementos faltantes se empaquetan directamente junto con la aplicación. Al formar el contenedor, el contenido del runtime se monta como la sección /usr, y el bundle se monta en el directorio /app.
El contenido del runtime y de los contenedores de aplicaciones se forma utilizando la tecnología OSTree, en la cual la imagen se actualiza de manera atómica desde un repositorio similar a Git, lo que permite aplicar métodos de control de versiones a los componentes de la distribución (por ejemplo, se puede revertir rápidamente el sistema a un estado anterior). Los paquetes RPM se traducen al repositorio OSTree mediante una capa especial llamada rpm-ostree. No se admite la instalación y actualización de paquetes por separado dentro del entorno de trabajo, el sistema se actualiza no a nivel de componentes individuales, sino en su totalidad, cambiando su estado de manera atómica. Se proporcionan herramientas para la aplicación incremental de actualizaciones, eliminando la necesidad de reemplazar toda la imagen en cada actualización.
El entorno aislado que se forma es completamente independiente de la distribución utilizada y, con la configuración adecuada del paquete, no tiene acceso a los archivos y procesos del usuario o del sistema principal, ni puede acceder directamente al hardware, salvo la salida a través de DRI y los accesos a la subsistema de red. La salida gráfica y la organización de la entrada se realizan mediante el protocolo Wayland o a través del reenvío del socket X11. La interacción con el entorno externo se basa en el sistema de mensajería DBus y una API especial llamada Portals.
Para el aislamiento se utiliza una capa de Bubblewrap y tecnologías tradicionales de virtualización de contenedores en Linux, basadas en el uso de cgroups, espacios de nombres (namespaces), Seccomp y SELinux. Para la salida de sonido se emplea PulseAudio. Sin embargo, el aislamiento puede ser desactivado, lo que es aprovechado por los desarrolladores de muchos paquetes populares para obtener acceso completo al sistema de archivos y a todos los dispositivos en el sistema. Por ejemplo, paquetes como GIMP, VSCodium, PyCharm, Octave, Inkscape, Audacity y VLC vienen con un modo de aislamiento limitado que deja el acceso completo al directorio personal. En caso de que se comprometan paquetes con acceso al directorio personal, a pesar de que el paquete esté etiquetado como «sandboxed», al atacante le basta con modificar el archivo ~/ .bashrc para ejecutar su código. Un tema aparte es el control sobre los cambios en los paquetes y la confianza en los creadores de paquetes, que a menudo no están relacionados con el proyecto principal o las distribuciones.
Fuente: opennet.ru
