Opublikowana została nowa stabilna wersja narzędzia Flatpak 1.14, które zapewnia system do budowy samowystarczalnych pakietów, niezwiązanych z konkretnymi dystrybucjami Linuxa, uruchamianych w specjalnym kontenerze, który izoluje aplikację od reszty systemu. Wsparcie dla uruchamiania pakietów Flatpak zapewniono dla Arch Linux, CentOS, Debian, Fedora, Gentoo, Mageia, Linux Mint, Alt Linux i Ubuntu. Pakiety Flatpak zostały uwzględnione w repozytorium Fedory i są wspierane przez wbudowany program do zarządzania aplikacjami GNOME.
Kluczowe nowości w wersji Flatpak 1.14:
- Zapewniono tworzenie katalogu dla plików w stanie (.local/state) oraz ustawienie zmiennej środowiskowej XDG_STATE_HOME wskazującej na ten katalog.
- Dodano warunkowe sprawdzenia w postaci „have-kernel-module-nazwa” do określenia obecności modułów jądra (uniwersalny odpowiednik wcześniej proponowanej kontroli have-intel-gpu, którego teraz można używać jako „have-kernel-module-i915”).
- Wprowadzono polecenie „flatpak document-unexport —doc-id=…”.
- Zapisano metadane Appstream do użycia w głównym środowisku.
- Dodano zasady automatycznego uzupełniania poleceń flatpak dla powłoki Fish.
- Zezwolono na dostęp sieciowy do usług X11 i PulseAudio (po dodaniu odpowiednich ustawień).
- Główna gałąź w repozytorium Git została przemianowana z „master” na „main”, ponieważ słowo „master” w ostatnim czasie uważane jest za niepoprawne politycznie.
- Zapewniono ponowne zapisanie skryptów uruchamiających w przypadku zmiany nazwy aplikacji.
- Do polecenia install dodano opcje „—include-sdk” i „—include-debug” do instalacji SDK i plików debuginfo.
- Do plików flatpakref i flatpakrepo dodano wsparcie dla parametru „DeploySideloadCollectionID”, dzięki czemu identyfikator kolekcji będzie ustawiany podczas dodawania zdalnego repozytorium, a nie po pobraniu metadanych.
- Zezwolono na tworzenie zagnieżdżonych środowisk sandboxowych dla obsługiwanych w sesjach o unikalnych nazwach MPRIS (Media Player Remote Interfacing Specification).
- W narzędziach wiersza poleceń zapewniono wyjście informacji na temat użycia przestarzałych rozszerzeń runtime.
- W poleceniu uninstall wprowadzono prośbę o potwierdzenie przed usunięciem runtime lub runtime-rozszerzeń, które są jeszcze w użyciu.
- Do poleceń podobnych do „flatpak run” dodano wsparcie dla opcji „—socket=gpg-agent”.
- W libostree naprawiono lukę, która potencjalnie pozwalała użytkownikowi na usunięcie dowolnych plików w systemie poprzez manipulacje z obsługiwaczem flatpak-system-helper (wysyłając żądanie usunięcia z odpowiednio sformatowaną nazwą gałęzi). Problem występuje jedynie w starych wersjach Flatpaka i libostree wydanych przed 2018 rokiem (< 0.10.2) i nie dotyczy aktualnych wydań.
Przypomnijmy, że programiści aplikacji Flatpak mają możliwość uproszczenia dystrybucji swoich programów, które nie są częścią standardowych repozytoriów dystrybucji, dzięki przygotowaniu jednego uniwersalnego kontenera bez potrzeby tworzenia oddzielnych kompilacji dla każdej dystrybucji. Użytkownikom, którzy dbają o bezpieczeństwo, Flatpak pozwala na uruchomienie budzącej wątpliwości aplikacji w kontenerze, udostępniając dostęp tylko do funkcji sieciowych i plików użytkownika związanych z aplikacją. Użytkownikom zainteresowanym nowinkami, Flatpak umożliwia instalację najnowszych wersji testowych i stabilnych aplikacji bez potrzeby wprowadzania zmian w systemie. Na przykład, pakiety Flatpak są tworzone dla LibreOffice, Midori, GIMP, Inkscape, Kdenlive, Steam, 0 A.D., Visual Studio Code, VLC, Slack, Skype, Telegram Desktop, Android Studio itd.
Aby zmniejszyć rozmiar pakietu, zawiera on tylko specyficzne dla aplikacji zależności, podczas gdy podstawowe biblioteki systemowe i graficzne (GTK, Qt, biblioteki GNOME i KDE itd.) są przedstawione jako modułowe standardowe środowiska uruchomieniowe. Kluczową różnicą między Flatpak a Snap jest to, że Snap wykorzystuje komponenty środowiska głównego systemu i izolację opartą na filtracji wywołań systemowych, podczas gdy Flatpak tworzy osobny kontener od systemu i operuje na dużych zestawach środowisk uruchomieniowych, udostępniając jako zależności nie pakiety, lecz standardowe środowiska systemowe (na przykład wszystkie biblioteki niezbędne do działania programów GNOME lub KDE).
Oprócz typowego środowiska systemowego (runtime), instalowanego za pośrednictwem specjalnego repozytorium, dostarczane są dodatkowe zależności (bundle), wymagane do działania aplikacji. W sumie runtime i bundle tworzą zawartość kontenera, przy czym runtime jest instalowany oddzielnie i jest powiązany z wieloma kontenerami, co pozwala uniknąć duplikowania wspólnych dla kontenerów plików systemowych. W jednym systemie może być zainstalowanych kilka różnych runtime'ów (GNOME, KDE) lub kilka wersji jednego runtime'u (GNOME 3.40, GNOME 3.42). Kontener z aplikacją jako zależnością wykorzystuje powiązanie tylko z określonym runtime, bez uwzględniania pojedynczych pakietów, z których składa się runtime. Wszystkie brakujące elementy są pakowane bezpośrednio razem z aplikacją. Podczas tworzenia kontenera zawartość runtime jest montowana jako lokalizacja /usr, a bundle montowane jest w katalogu /app.
Zawartość runtime i kontenerów aplikacji jest tworzona z wykorzystaniem technologii OSTree, w której obraz atomowo aktualizowany jest z repozytorium podobnego do Git, co pozwala stosować metody kontroli wersji do komponentów dystrybucji (na przykład można szybko przywrócić system do poprzedniego stanu). Pakiety RPM są tłumaczone do repozytorium OSTree za pomocą specjalnej warstwy rpm-ostree. Oddzielna instalacja i aktualizacja pakietów wewnątrz środowiska roboczego nie jest wspierana, system aktualizowany jest nie na poziomie pojedynczych komponentów, ale w całości, atomowo zmieniając swoje stany. Dostarczane są narzędzia do inkrementalnego stosowania aktualizacji, eliminujące potrzebę pełnej wymiany obrazu przy każdej aktualizacji.
Tworzone izolowane środowisko jest całkowicie niezależne od używanej dystrybucji i przy odpowiednich ustawieniach pakietu nie ma dostępu do plików i procesów użytkownika lub systemu głównego, nie może bezpośrednio łączyć się z urządzeniem, z wyjątkiem wyjścia przez DRI, oraz połączeń z systemem sieciowym. Wyjście grafiki i organizacja wejścia są realizowane za pomocą protokołu Wayland lub przez przekazywanie gniazda X11. Interakcja z otoczeniem opiera się na systemie wymiany komunikatów DBus i specjalnym API Portals.
Do izolacji używana jest warstwa Bubblewrap oraz tradycyjne technologie wirtualizacji kontenerów w systemie Linux, oparte na wykorzystaniu cgroups, przestrzeni nazw (namespaces), Seccomp i SELinux. Do wyjścia dźwięku stosowany jest PulseAudio. Izolację można wyłączyć, z czego korzystają deweloperzy wielu popularnych pakietów, aby uzyskać pełny dostęp do systemu plików i wszystkich urządzeń. Na przykład, pakiety takie jak GIMP, VSCodium, PyCharm, Octave, Inkscape, Audacity i VLC są dostarczane w wersji z ograniczonym trybem izolacji, który pozostawia pełny dostęp do katalogu domowego. W przypadku kompromitacji pakietów mających dostęp do katalogu domowego, pomimo że w opisie pakietu znajduje się oznaczenie „sandboxed”, atakujący może łatwo zmodyfikować plik ~\/bashrc, aby wykonać swój kod. Osobnym zagadnieniem jest kontrola nad wprowadzanymi zmianami w pakietach oraz zaufanie do twórców pakietów, którzy często nie są związani z głównym projektem lub dystrybucjami.
Źródło: opennet.ru
