Er is een nieuwe stabiele tak van de Flatpak 1.14 toolkit gepubliceerd, die een systeem biedt voor het bouwen van op zichzelf staande pakketten die niet gebonden zijn aan specifieke Linux-distributies en draaien in een speciale container die de applicatie isoleert van de rest van het systeem. Ondersteuning voor het uitvoeren van Flatpak-pakketten wordt geboden voor Arch Linux, CentOS, Debian, Fedora, Gentoo, Mageia, Linux Mint, Alt Linux en Ubuntu. Flatpak-pakketten zijn opgenomen in de Fedora-repository en worden ondersteund door de native GNOME-applicatiebeheerder.
Belangrijkste innovaties in de Flatpak 1.14-branche:
- Het is mogelijk om een map aan te maken voor bestanden in status (.local/state) en de omgevingsvariabele XDG_STATE_HOME in te stellen die naar deze map verwijst.
- Voorwaardelijke controles toegevoegd van het formulier “have-kernel-module-name” om de aanwezigheid van kernelmodules te bepalen (een universeel analoog van de eerder voorgestelde have-intel-gpu-controle, in plaats van de uitdrukking “have-kernel-module-i915 ” kan nu worden gebruikt).
- De opdracht “flatpak document-unexport —doc-id=...” is geïmplementeerd.
- Export van Appstream-metadata voor gebruik in de hoofdomgeving is voorzien.
- Flatpak-opdrachtvoltooiingsregels toegevoegd voor de visschelp
- Netwerktoegang tot X11- en PulseAudio-services is toegestaan (als de juiste instellingen zijn toegevoegd).
- De hoofdtak in de Git-repository is hernoemd van “master” naar “main”, omdat het woord “master” onlangs als politiek incorrect werd beschouwd.
- Startscripts worden nu herschreven als de toepassing wordt hernoemd.
- Opties "--include-sdk" en "--include-debug" toegevoegd aan de install-opdracht om de SDK- en debuginfo-bestanden te installeren.
- Ondersteuning toegevoegd voor de parameter "DeploySideloadCollectionID" aan de flatpakref- en flatpakrepo-bestanden. Indien ingesteld, wordt de collectie-ID ingesteld bij het toevoegen van een externe repository, en niet na het laden van de metagegevens.
- Maakte de creatie mogelijk van geneste sandbox-omgevingen voor handlers in sessies met afzonderlijke MPRIS-namen (Media Player Remote Interfacing Specification).
- Commandoregelhulpprogramma's bieden nu informatie over het gebruik van verouderde runtime-extensies.
- De verwijderopdracht implementeert een bevestigingsverzoek voordat runtime of runtime-extensies worden verwijderd die nog in gebruik zijn.
- Ondersteuning toegevoegd voor de optie “--socket=gpg-agent” voor opdrachten als “flatpak run”.
- Er is een kwetsbaarheid opgelost in libostree waardoor een gebruiker mogelijk willekeurige bestanden op het systeem kan verwijderen door manipulatie van de flatpak-system-helper handler (het verzenden van een verwijderverzoek met een speciaal opgemaakte branchnaam). Het probleem doet zich alleen voor in oudere versies van Flatpak en libostree die vóór 2018 zijn uitgebracht (<0.10.2) en heeft geen invloed op huidige releases.
Laten we u eraan herinneren dat Flatpak applicatieontwikkelaars in staat stelt de distributie van hun programma's die niet zijn opgenomen in de standaard distributierepository's te vereenvoudigen door één universele container voor te bereiden zonder voor elke distributie afzonderlijke assemblages te maken. Voor veiligheidsbewuste gebruikers kunt u met Flatpak een twijfelachtige applicatie in een container uitvoeren, waarbij u alleen toegang krijgt tot de netwerkfuncties en gebruikersbestanden die aan de applicatie zijn gekoppeld. Voor gebruikers die geïnteresseerd zijn in nieuwe producten, kunt u met Flatpak de nieuwste test- en stabiele releases van applicaties installeren zonder dat u wijzigingen aan het systeem hoeft aan te brengen. Flatpak-pakketten zijn bijvoorbeeld gebouwd voor LibreOffice, Midori, GIMP, Inkscape, Kdenlive, Steam, 0 AD, Visual Studio Code, VLC, Slack, Skype, Telegram Desktop, Android Studio, enz.
Om de pakketgrootte te verkleinen, bevat het alleen applicatiespecifieke afhankelijkheden, en zijn de basissysteem- en grafische bibliotheken (GTK-, Qt-, GNOME- en KDE-bibliotheken, enz.) ontworpen als plug-in standaard runtime-omgevingen. Het belangrijkste verschil tussen Flatpak en Snap is dat Snap de componenten van de hoofdsysteemomgeving en isolatie gebruikt op basis van het filteren van systeemaanroepen, terwijl Flatpak een container creëert die gescheiden is van het systeem en werkt met grote runtimesets, waarbij pakketten niet als afhankelijkheden worden aangeboden, maar standaard de systeemomgevingen (bijvoorbeeld alle bibliotheken die nodig zijn voor de werking van GNOME- of KDE-programma's).
Naast de standaard systeemomgeving (runtime), geïnstalleerd via een speciale repository, worden aanvullende afhankelijkheden (bundel) geleverd die nodig zijn voor de werking van de applicatie. In totaal vormen runtime en bundel de vulling van de container, ondanks het feit dat runtime afzonderlijk wordt geïnstalleerd en aan meerdere containers tegelijk is gekoppeld, waardoor u het dupliceren van systeembestanden kunt voorkomen die gebruikelijk zijn bij containers. Op één systeem kunnen meerdere verschillende runtimes geïnstalleerd zijn (GNOME, KDE) of meerdere versies van dezelfde runtime (GNOME 3.40, GNOME 3.42). Een container met een applicatie als afhankelijkheid gebruikt alleen een binding aan een specifieke runtime, zonder rekening te houden met de individuele pakketten waaruit de runtime bestaat. Alle ontbrekende elementen worden direct bij de applicatie verpakt. Wanneer een container wordt gevormd, wordt de runtime-inhoud aangekoppeld als de /usr-partitie, en wordt de bundel aangekoppeld in de map /app.
De runtime- en applicatiecontainers zijn gebouwd met behulp van OSTree-technologie, waarbij de afbeelding atomair wordt bijgewerkt vanuit een Git-achtige repository, waardoor versiebeheermethoden kunnen worden toegepast op de distributiecomponenten (u kunt het systeem bijvoorbeeld snel terugdraaien naar een vorige staat). RPM-pakketten worden vertaald naar de OSTree-repository met behulp van een speciale rpm-ostree-laag. Afzonderlijke installatie en update van pakketten binnen de werkomgeving wordt niet ondersteund; het systeem wordt niet bijgewerkt op het niveau van individuele componenten, maar als geheel, waardoor de staat ervan atomair verandert. Biedt tools om updates stapsgewijs toe te passen, waardoor het niet meer nodig is om de image bij elke update volledig te vervangen.
De gegenereerde geïsoleerde omgeving is volledig onafhankelijk van de gebruikte distributie en heeft bij de juiste pakketinstellingen geen toegang tot bestanden en processen van de gebruiker of het hoofdsysteem, en kan ook niet direct toegang krijgen tot de apparatuur, met uitzondering van uitvoer via DRI en oproepen naar het netwerksubsysteem. Grafische uitvoer en invoerorganisatie worden geïmplementeerd met behulp van het Wayland-protocol of via X11-socket forwarding. Interactie met de externe omgeving is gebaseerd op het DBus-berichtensysteem en een speciale Portals API.
Voor isolatie wordt gebruik gemaakt van de Bubblewrap-laag en traditionele Linux-containervirtualisatietechnologieën, gebaseerd op het gebruik van cgroups, naamruimten, Seccomp en SELinux. PulseAudio wordt gebruikt om geluid uit te voeren. In dit geval kan isolatie worden uitgeschakeld, wat door de ontwikkelaars van veel populaire pakketten wordt gebruikt om volledige toegang te krijgen tot het bestandssysteem en alle apparaten in het systeem. GIMP, VSCodium, PyCharm, Octave, Inkscape, Audacity en VLC worden bijvoorbeeld geleverd met een beperkte isolatiemodus die volledige toegang tot de thuismap geeft. Als pakketten met toegang tot de homedirectory in gevaar komen, ondanks de aanwezigheid van het label “sandboxed” in de pakketbeschrijving, hoeft de aanvaller alleen het bestand ~/.bashrc te wijzigen om zijn code uit te voeren. Een apart probleem is de controle over wijzigingen aan pakketten en het vertrouwen in pakketbouwers, die vaak niet geassocieerd zijn met het hoofdproject of de distributies.
Bron: opennet.ru