Udgivelse af Flatpak 1.14.0 autonome pakke-system

Den nye stabile version af Flatpak værktøjet 1.14 er offentliggjort, som giver et system til at opbygge autonome pakker, der ikke er knyttet til specifikke Linux-distributioner og kører i en speciel container, der isolerer applikationen fra resten af systemet. Understøttelse af kørsel af Flatpak-pakker er sikret for Arch Linux, CentOS, Debian, Fedora, Gentoo, Mageia, Linux Mint, Alt Linux og Ubuntu. Flatpak-pakker er inkluderet i Fedora-repositoriet og understøttes af standard GNOME applikationsadministrationsprogram.

Nøglefunktioner i Flatpak 1.14:

  • Der er sikret oprettelse af katalog til filer i tilstanden (.local/state) og sat miljøvariablen XDG_STATE_HOME, der peger på dette katalog.
  • Betingede tjek af typen "have-kernel-module-navn" er tilføjet for at bestemme tilstedeværelsen af kernelmoduler (et universelt alternativ til den tidligere foreslåede tjek "have-intel-gpu", som nu kan erstattes med udtrykket "have-kernel-module-i915").
  • Implementeret kommandoen "flatpak document-unexport --doc-id=…".
  • Eksport af Appstream metadata er sikret til brug i det primære miljø.
  • Auto-fuldførelse regler for flatpak-kommandoer er tilføjet til Fish shell.
  • Netværksadgang til X11 og PulseAudio tjenester er tilladt (ved tilføjelse af de relevante indstillinger).
  • Den primære gren i Git-repositoriet er omdøbt fra "master" til "main", da ordet "master" på det seneste betragtes som politisk ukorrekt.
  • Oprettelse af opstartsscripts er sikret i tilfælde af omdøbning af applikationen.
  • Installationen har fået tilføjet mulighederne "--include-sdk" og "--include-debug" for installation af SDK og debuginfo-filer.
  • Støtte til parameteren "DeploySideloadCollectionID" er tilføjet i flatpakref og flatpakrepo filer, hvorved kollektions-id'et sættes under tilføjelsen af det fjernlagrede repository, i stedet for efter download af metadata.
  • Oprettelse af indlejrede sandbox-miljøer til behandlere i sessioner med separate navn MPRIS (Media Player Remote Interfacing Specification) er tilladt.
  • I kommandolinjeværktøjerne er der sikret visning af oplysninger om brugen af forældede runtime-udvidelser.
  • I uninstall-kommandoen er der implementeret en bekræftelsesforespørgsel før sletning af runtime eller runtime-udvidelser, der stadig er i brug.
  • I kommandoer som "flatpak run" er der tilføjet understøttelse af parameteren "--socket=gpg-agent".
  • I libostree er der rettet en sårbarhed, som potentielt kan give en bruger mulighed for at slette vilkårlige filer i systemet ved at manipulere med flatpak-systemhjælperen (ved at sende anmodning om sletning med et specielt udformet navn på grenen). Problemet opstår kun i ældre versioner af Flatpak og libostree, der er udgivet før 2018 (< 0.10.2), og berører ikke de aktuelle udgivelser.

Husk, at Flatpak giver app-udviklere mulighed for at forenkle distributionen af deres programmer, der ikke findes i de officielle pakke-repositorier, ved at forberede en universel container uden at skulle lave separate builds til hver distribution. For brugere, der bekymrer sig om sikkerhed, giver Flatpak mulighed for at køre tvivlsomme applikationer i en container, der kun giver adgang til netværksfunktioner og brugerfiler relateret til applikationen. For brugere, der er interesseret i nyheder, gør Flatpak det muligt at installere de nyeste test- og stabile versioner af apps uden at skulle ændre systemet. For eksempel oprettes Flatpak-pakker til LibreOffice, Midori, GIMP, Inkscape, Kdenlive, Steam, 0 A.D., Visual Studio Code, VLC, Slack, Skype, Telegram Desktop, Android Studio osv.

For at reducere pakkestørrelsen inkluderer den kun specifikke anvendelsesafhængigheder, mens de grundlæggende system- og grafiske biblioteker (GTK, Qt, biblioteker fra GNOME og KDE osv.) er arrangeret som plug-in typiske runtime-miljøer. Den væsentligste forskel mellem Flatpak og Snap er, at Snap bruger komponenter fra det primære systems miljø og isolering baseret på filtrering af systemopkald, mens Flatpak opretter en separat container fra systemet og opererer med store runtime-sæt og leverer som afhængigheder ikke pakker, men typiske systemmiljøer (f.eks. alle biblioteker, der er nødvendige for at køre GNOME- eller KDE-programmer).

Udover det typiske systemmiljø (runtime), der installeres via et specielt repository, leveres der yderligere afhængigheder (bundle), som er nødvendige for applikationens funktion. Sammen udgør runtime og bundle indholdet af containeren, idet runtime installeres separat og knyttes til flere containere, hvilket gør det muligt at undgå duplikering af fælles systemfiler for containerne. I et system kan der være installeret flere forskellige runtime (GNOME, KDE) eller flere versioner af en enkelt runtime (GNOME 3.40, GNOME 3.42). Containere med applikationer som afhængighed bruger bindingen kun til et bestemt runtime uden at tage højde for de enkelte pakker, som runtime består af. Alle manglende elementer pakkes direkte sammen med applikationen. Ved oprettelse af containeren monteres indholdet af runtime som partition \/usr, mens bundle monteres i mappen \/app.

Indholdet af runtime og applikationscontainere dannes ved hjælp af OSTree-teknologi, hvor billedet atomart opdateres fra et Git-lignende lager, der muliggør anvendelse af versionskontrolmetoder på komponenterne i distributionen (for eksempel kan systemet hurtigt rulles tilbage til en tidligere tilstand). RPM-pakker oversættes til OSTree-repositoryet ved hjælp af et specielt lag rpm-ostree. Separat installation og opdatering af pakker inden for det arbejdsmiljø understøttes ikke, systemet opdateres ikke på niveauet af individuelle komponenter, men som helhed, atomart ændrende sin tilstand. Der stilles midler til rådighed for inkrementelle anvendelser af opdateringer, der fjerner behovet for en fuld erstatning af billedet ved hver opdatering.

Det isolerede miljø, der dannes, er fuldstændig uafhængigt af det anvendte distribution og har ved passende pakkeindstillinger ikke adgang til brugerens eller hovedsystemets filer og processer, kan ikke direkte tilgå hardware, undtagen ved uddata gennem DRI, og ved anmodninger til netværkssystemet. Grafikudgang og inputorganisationen gennemføres ved hjælp af Wayland-protokollen eller via X11 socket-passthrough. Interaktion med den eksterne verden er baseret på DBus-messagesystemet og et særligt API Portals.

Bubblewrap fungerer som isolationslag og anvender de traditionelle Linux-teknologier til container-virtualisering, baseret på brug af cgroups, navnerum (namespaces), Seccomp og SELinux. PulseAudio bruges til lydudgang. Isolationen kan dog slås fra, hvilket mange udviklere af populære pakker udnytter for at få fuld adgang til filsystemet og alle enheder i systemet. For eksempel leveres pakker som GIMP, VSCodium, PyCharm, Octave, Inkscape, Audacity og VLC med en begrænset isolationsmode, der giver fuld adgang til hjemmemappen. I tilfælde af kompromittering af pakker med adgang til hjemmemappen, er det nok for en angriber at ændre filen ~/ .bashrc, på trods af at pakken beskrives som 'sandboxed'. Et separat spørgsmål er kontrol over ændringer i pakker og tillid til pakkesamlere, som ofte ikke er knyttet til hovedprojektet eller distributionerne.

Kilde: opennet.ru

Køb pålidelig webhosting med DDoS-beskyttelse, VPS VDS-servere 🔥 Køb pålidelig webhosting med DDoS-beskyttelse, VPS VDS-servere | ProHoster