new stable branch of the toolkit , which provides a system for building self-contained packages that are not tied to specific Linux distributions and run in a special container, isolating the application from the rest of the system. Support for running Flatpak packages is provided for Arch Linux, , Debian, Fedora, Gentoo, Mageia, Linux Mint, and Ubuntu. Flatpak packages are included in the Fedora repository and are supported in the GNOME application management program by default.
Key in the Flatpak 1.6 branch:
- In a method CreateUpdateMonitor has been added, allowing applications to track the availability of updates and request the installation of available updates.
To prevent the application from having permissions for self-installing updates, you can use the command 'flatpak permission-set flatpak updates $APPID no' (if you specify 'ask' instead of 'no', a dialog will appear each time for confirming the update); - To simplify the creation of handlers, a library has been proposed
libportal, which allows handling events without directly using the API Portal and parsing signals coming through D-Bus.
Libportal provides simple asynchronous layers for most 'Ā«; - A new permission '--socket=cups' has been added for providing direct access to the CUPS print server;
- The protocol and API for handling authentication have been changed. An authenticator for OCI (Open Container Initiative) has been added. Support for automatically installing authenticators from an external flatpak repository has been implemented. A callback handler has been added to FlatpakTransaction for using authentication via login and password similar to the HTTP basic authentication method;
- Support for secure applications and systems requiring authentication on startup has been added;
- The layer bubblewrap used for isolation has been updated to the release ;
- Optional parental control support has been added through the use of the library , allowing access to certain types of content to be restricted;
- Extensions are now installed before the application, allowing a working application to be available immediately after its installation is completed;
- Operations with temporary files have been redesigned, which has improved performance under conditions of limited free disk space.
- The command Ā«Ā» no longer requires the use of sudo;
- Portals now support running nested isolated environments (sub-sandbox) for child processes;
- New commands Ā«flatpak permission-setĀ» and Ā«permission-removeĀ» have been added for managing permission installations;
- The option Ā«flatpak install āor-updateĀ» has been implemented to update if the application is already installed;
- The command Ā«flatpak maskĀ» has been added to lock a version and prevent updates from being installed;
- Support for binding labels, generating change histories in images, and including Docker mime types, in addition to OCI mime types, has been added for images in OCI (Open Container Initiative) format;
- A default-languages key has been added to settings to define the list of languages used, in addition to the system list.
Letās remember that Flatpak gives application developers the opportunity to simplify the distribution of their programs not included in standard distribution repositories by a single universal container without creating separate builds for each distribution. For security-conscious users, Flatpak allows running potentially suspicious applications in a container, granting access only to network functions and user files related to the application. For users interested in new releases, Flatpak enables the installation of the latest testing and stable versions of applications without needing to modify the system. For example, Flatpak packages are currently for LibreOffice, Firefox, GIMP, Inkscape, Kdenlive, Steam, 0 A.D., Visual Studio Code, VLC, Slack, Skype, Telegram Desktop, Android Studio, and more.
To reduce the package size, it only includes application-specific dependencies, while the base system and graphical libraries (Gtk+, Qt, GNOME, KDE libraries, etc.) are presented as plug-in standard runtime environments. The key distinction between Flatpak and Snap is that Snap uses components from the main system environment and isolation based on system call filtering, while Flatpak creates a container separate from the system and operates large sets of runtimes, providing standard system environments as dependencies (for example, all libraries required for running GNOME or KDE applications).
In addition to the standard system environment (runtime) installed via a special , additional dependencies (bundle) required for application operation are supplied. Together, the runtime and bundle form the contents of the container, with the runtime being installed separately and linked to several containers at once, thus avoiding duplication of shared system files among containers. Multiple different runtimes (GNOME, KDE) or several versions of one runtime (GNOME 3.26, GNOME 3.28) can be installed on one system. A container with the application as a dependency links only to a specific runtime, disregarding the individual packages that make up the runtime. All missing components are bundled directly with the application. When creating a container, the contents of the runtime are mounted as the partition /usr, while the bundle is mounted in the /app directory.
The contents of the runtime and application containers are formed using the technology , whereby the image is atomically updated from a Git-like repository, allowing version control methods to be applied to the components of the distribution (for example, the system can be quickly reverted to a previous state). RPM packages are transmitted to the OSTree repository through a special layer . Separate installation and updating of packages within the working environment is not supported; the system is updated not at the level of individual components but as a whole, atomically changing its state. Tools are provided for the incremental application of updates, alleviating the need for complete image replacement with each update.
The isolated environment being formed is completely independent of the distribution used, and with the proper package settings, it has no access to the files and processes of the user or the main system, and cannot directly access hardware, except for output via DRI and the network subsystem. Graphics output and input organization using the Wayland protocol or through X11 socket forwarding. Interaction with the external environment is based on the DBus messaging system and a special API Portals. For isolation is used and the traditional container virtualization technologies for Linux, based on the use of cgroups, namespaces, Seccomp, and SELinux. PulseAudio is used for sound output.
Source: opennet.ru
