Utgivelse av systemet for selvstendige pakker Flatpak 1.14.0

En ny stabil version av Flatpak-verktygssatsen 1.14 har publicerats, som tillhandahåller ett system för att bygga fristående paket som inte är bundna till specifika Linux-distributioner och som körs i en speciell behållare som isolerar applikationen från resten av systemet. Stöd för körning av Flatpak-paket har säkerställts för Arch Linux, CentOS, Debian, Fedora, Gentoo, Mageia, Linux Mint, Alt Linux och Ubuntu. Flatpak-paket är inkluderade i Fedora-repositoriet och stöds i det inbyggda applikationshanteringsprogrammet GNOME.

Nyckelnyheter i Flatpak 1.14-serien:

• Skapande av katalog för filer i tillstånd (.local/state) och fastställande av en miljövariabel för att peka på denna katalog, XDG_STATE_HOME, har säkerställts.
• Villkorliga kontroller av typen "have-kernel-module- namn" har lagts till för att bestämma närvaron av kärnmoduler (en universell motsvarighet till den tidigare föreslagna kontrollen have-intel-gpu, där det nu istället går att använda uttrycket "have-kernel-module-i915").
• Kommandot "flatpak document-unexport —doc-id=…" har implementerats.
• Export av Appstream-metadata för användning i huvudmiljön har säkerställts.
• Autocompletionsregler för Flatpak-kommandon har lagts till för kommandoraden Fish.
• Nätverksåtkomst till X11- och PulseAudio-tjänster har tillåtits (med rätt inställningar).
• Huvudgrenen i Git-repositoriet har döpts om från "master" till "main", eftersom ordet "master" under senare tid har ansetts politiskt inkorrekt.
• Överskrivning av startskript har säkerställts vid omdöpning av applikationen.
• Alternativen "—include-sdk" och "—include-debug" har lagts till i install-kommandot för installation av SDK och debuginfo-filer.
• Stödet för parametern "DeploySideloadCollectionID" har lagts till i flatpakref och flatpakrepo-filer, vilket gör att samlings-ID:t kommer att ställas in vid tillägg av det fjärran repositoriet, istället för efter att metadata har laddats ner.
• Skapande av inbäddade sandbox-miljöer för hanterare i sessioner med separata MPRIS-namn (Media Player Remote Interfacing Specification) har tillåtits.
• Verktygen för kommandoraden har säkerställt att information om användning av föråldrade runtime-tillägg visas.
• I uninstall-kommandot har en bekräftelsefråga införts innan borttagning av runtime eller runtime-tillägg som fortfarande används.
• I kommandon som "flatpak run" har stöd för alternativet "—socket=gpg-agent" lagts till.
• I libostree har en sårbarhet åtgärdats som potentiellt kan tillåta en användare att ta bort godtyckliga filer i systemet genom manipulation av flatpak-systemhelper (genom att skicka en begäran om borttagning med ett särskilt formaterat grennamn). Problemet uppstår endast i gamla versioner av Flatpak och libostree, som utfärdades före 2018 (< 0.10.2), och påverkar inte nuvarande utgåvor.

Det är viktigt att påminna om att Flatpak ger utvecklare av applikationer möjlighet att förenkla distributionen av sina program, som inte ingår i standardförråden för distributioner, genom att förbereda en universell container utan att behöva skapa separata versioner för varje distribution. Användare som värnar om säkerhet kan köra tveksamma applikationer i en container som ger åtkomst endast till nätverksfunktioner och användarfiler relaterade till applikationen. Användare som är intresserade av nyheter kan installera de senaste test- och stabila versionerna av applikationer utan att behöva göra ändringar i systemet. Till exempel byggs Flatpak-paket för LibreOffice, Midori, GIMP, Inkscape, Kdenlive, Steam, 0 A.D., Visual Studio Code, VLC, Slack, Skype, Telegram Desktop, Android Studio etc.

För att minska paketets storlek ingår endast applikationsspecifika beroenden, medan grundläggande system- och grafiska bibliotek (GTK, Qt, GNOME och KDE-bibliotek etc.) presenteras som anslutningsbara standardruntime-miljöer. Huvudskillnaden mellan Flatpak och Snap är att Snap använder komponenter från det underliggande systemet och isolering baserat på filtrering av systemanrop, medan Flatpak skapar en separat container från systemet och opererar med stora runtime-satser, vilket tillhandahåller standardiserade systemmiljöer (till exempel alla bibliotek som krävs för att köra GNOME- eller KDE-program).

Förutom den typiska systemmiljön (runtime) som installeras via ett särskilt lager, levereras ytterligare beroenden (bundle) som krävs för att applikationen ska fungera. Tillsammans utgör runtime och bundle innehållet i containern, där runtime installeras separat och kan kopplas till flera containrar, vilket förhindrar duplicering av gemensamma systemfiler för containrar. Flera olika runtime (GNOME, KDE) eller flera versioner av samma runtime (GNOME 3.40, GNOME 3.42) kan installeras på ett system. Containern med applikationen som beroende använder bindningen endast till en specifik runtime, utan att ta hänsyn till de enskilda paketen som utgör runtime. Alla saknade element packas tillsammans med applikationen. Vid skapandet av containern monteras innehållet i runtime som delen /usr, medan bundle monteras i katalogen /app.

Innehållet i runtime och applikationscontainrar skapas med hjälp av teknologin OSTree, där bilden atomärt uppdateras från ett Git-liknande arkiv, vilket möjliggör tillämpning av versionshanteringsmetoder på distributionskomponenter (till exempel kan systemet snabbt återställas till ett tidigare tillstånd). RPM-paket översätts till OSTree-förvaret med hjälp av ett särskilt lager rpm-ostree. Separat installation och uppdatering av paket inom arbetsmiljön stöds inte, systemet uppdateras inte på nivån av enskilda komponenter utan helt, och ändrar atomärt sitt tillstånd. Verkyg erbjuds för inkrementell tillämpning av uppdateringar, vilket eliminerar behovet av att helt byta bild vid varje uppdatering.

Det isolerade miljön som skapas är helt oberoende av den använda distributionen och, vid korrekt paketering, har ingen åtkomst till användarens eller huvudsystemets filer och processer, kan inte direkt interagera med hårdvaran, förutom utmatning via DRI, och anrop till nätverksystemet. Grafikutmatning och hantering av inmatning realiseras med protokollet Wayland eller genom vidarekoppling av X11-socket. Interaktionen med den externa miljön baseras på meddelandebytesystemet DBus och ett särskilt API för Portals.

För isolering används ett skikt av Bubblewrap och traditionella Linux-teknologier för containervirtualisering, baserade på användning av cgroups, namnrymder (namespaces), Seccomp och SELinux. PulseAudio används för ljudutmatning. Isoleringen kan dock stängas av, vilket utnyttjas av utvecklare av många populära paket för att få full tillgång till filsystemet och alla enheter i systemet. Till exempel levereras paket som GIMP, VSCodium, PyCharm, Octave, Inkscape, Audacity och VLC med en begränsad isoleringsläge som låter full tillgång till hemkatalogen. Vid komprometterade paket med tillgång till hemkatalogen, trots en märkning av paketets beskrivning med "sandboxed", räcker det för en angripare att ändra filen ~\/ .bashrc för att köra sin kod. En separat fråga är kontrollen över ändringar i paketen och förtroendet för paketbyggare, som ofta inte är kopplade till huvudprojektet eller distributioner.

Källa: opennet.ru