Frigivelse af Flatpak 1.14.0 selvstændigt pakkesystem

En ny stabil gren af ​​Flatpak 1.14-værktøjssættet er blevet offentliggjort, som giver et system til at bygge selvstændige pakker, der ikke er bundet til specifikke Linux-distributioner og køres i en speciel container, der isolerer applikationen fra resten af ​​systemet. Support til at køre Flatpak-pakker er givet til Arch Linux, CentOS, Debian, Fedora, Gentoo, Mageia, Linux Mint, Alt Linux og Ubuntu. Flatpak-pakker er inkluderet i Fedora-lageret og understøttes af den oprindelige GNOME-applikationsadministrator.

Vigtigste innovationer i Flatpak 1.14-grenen:

  • Det er muligt at oprette en mappe for filer i tilstand (.local/state) og indstille XDG_STATE_HOME miljøvariablen til at pege på denne mappe.
  • Tilføjet betingede kontroller af formen "have-kernel-module-name" for at bestemme tilstedeværelsen af ​​kernemoduler (en universel analog af det tidligere foreslåede have-intel-gpu-tjek, i stedet for hvilket udtrykket "have-kernel-module-i915 ” kan nu bruges).
  • Kommandoen "flatpak document-unexport —doc-id=..." er blevet implementeret.
  • Eksport af Appstream-metadata til brug i hovedmiljøet leveres.
  • Tilføjet regler for udførelse af flatpak-kommandoer for fiskeskallen
  • Netværksadgang til X11- og PulseAudio-tjenester er tilladt (hvis de relevante indstillinger er tilføjet).
  • Hovedgrenen i Git-depotet er blevet omdøbt fra "master" til "main", da ordet "master" for nylig er blevet betragtet som politisk ukorrekt.
  • Startscripts omskrives nu, hvis programmet omdøbes.
  • Tilføjede mulighederne "--include-sdk" og "--include-debug" til installationskommandoen for at installere SDK- og debuginfo-filerne.
  • Tilføjet understøttelse af parameteren "DeploySideloadCollectionID" til flatpakref- og flatpakrepo-filerne. Når det er indstillet, vil samlings-id'et blive indstillet ved tilføjelse af et fjernlager og ikke efter indlæsning af metadata.
  • Tilladt oprettelse af indlejrede sandkassemiljøer for handlere i sessioner med separate MPRIS-navne (Media Player Remote Interfacing Specification).
  • Kommandolinjeværktøjer giver nu oplysninger om brugen af ​​forældede runtime-udvidelser.
  • Afinstallationskommandoen implementerer en bekræftelsesanmodning før fjernelse af runtime- eller runtime-udvidelser, der stadig er i brug.
  • Tilføjet understøttelse af "--socket=gpg-agent" muligheden til kommandoer som "flatpak run".
  • En sårbarhed er blevet rettet i libotree, der potentielt kan tillade en bruger at slette vilkårlige filer på systemet gennem manipulation af flatpak-system-helper-behandleren (sende en sletteanmodning med et specielt formateret filialnavn). Problemet optræder kun i ældre versioner af Flatpak og libotree udgivet før 2018 (< 0.10.2) og påvirker ikke aktuelle udgivelser.

Lad os minde dig om, at Flatpak tillader applikationsudviklere at forenkle distributionen af ​​deres programmer, der ikke er inkluderet i standard distributionslagre, ved at forberede en universel container uden at oprette separate samlinger for hver distribution. For sikkerhedsbevidste brugere giver Flatpak dig mulighed for at køre en tvivlsom applikation i en container, der kun giver adgang til netværksfunktioner og brugerfiler, der er knyttet til applikationen. For brugere, der er interesseret i nye produkter, giver Flatpak dig mulighed for at installere de seneste test- og stabile udgivelser af applikationer uden at skulle foretage ændringer i systemet. For eksempel er Flatpak-pakker bygget til LibreOffice, Midori, GIMP, Inkscape, Kdenlive, Steam, 0 AD, Visual Studio Code, VLC, Slack, Skype, Telegram Desktop, Android Studio osv.

For at reducere pakkestørrelsen inkluderer den kun applikationsspecifikke afhængigheder, og de grundlæggende system- og grafikbiblioteker (GTK, Qt, GNOME og KDE biblioteker osv.) er designet som plug-in standard runtime miljøer. Den vigtigste forskel mellem Flatpak og Snap er, at Snap bruger komponenterne i hovedsystemmiljøet og isolation baseret på filtrering af systemkald, mens Flatpak opretter en container adskilt fra systemet og opererer med store runtime-sæt, der ikke leverer pakker som afhængigheder, men standard sine systemmiljøer (for eksempel alle biblioteker, der er nødvendige for driften af ​​GNOME- eller KDE-programmer).

Ud over standard systemmiljøet (runtime), installeret gennem et særligt lager, leveres yderligere afhængigheder (bundle), der kræves til driften af ​​applikationen. I alt udgør runtime og bundle fyldningen af ​​containeren, på trods af at runtime er installeret separat og bundet til flere containere på én gang, hvilket giver dig mulighed for at undgå duplikering af systemfiler, der er fælles for containere. Et system kan have flere forskellige kørselstider installeret (GNOME, KDE) eller flere versioner af samme kørselstid (GNOME 3.40, GNOME 3.42). En container med en applikation som afhængighed bruger kun en binding til en bestemt runtime, uden at tage højde for de individuelle pakker, der udgør runtime. Alle manglende elementer pakkes direkte sammen med applikationen. Når en container dannes, monteres runtime-indholdet som /usr-partitionen, og bundtet monteres i /app-mappen.

Runtime- og applikationsbeholderne er bygget ved hjælp af OSTree-teknologi, hvor billedet er atomisk opdateret fra et Git-lignende repository, som gør det muligt at anvende versionskontrolmetoder til distributionskomponenterne (f.eks. kan du hurtigt rulle systemet tilbage til en tidligere tilstand). RPM-pakker oversættes til OSTree-lageret ved hjælp af et specielt rpm-ostree-lag. Separat installation og opdatering af pakker i arbejdsmiljøet er ikke understøttet; systemet opdateres ikke på niveau med individuelle komponenter, men som helhed, ændrer dets tilstand atomisk. Giver værktøjer til at anvende opdateringer trinvist, hvilket eliminerer behovet for helt at erstatte billedet med hver opdatering.

Det genererede isolerede miljø er fuldstændig uafhængigt af den anvendte distribution og har med korrekte indstillinger af pakken ikke adgang til filer og processer for brugeren eller hovedsystemet, kan ikke direkte få adgang til udstyret, med undtagelse af output via DRI, og opkald til netværksundersystemet. Grafikoutput og inputorganisation implementeres ved hjælp af Wayland-protokollen eller via X11-socket-videresendelse. Interaktion med det eksterne miljø er baseret på DBus-meddelelsessystemet og en særlig Portals API.

Til isolering bruges Bubblewrap-laget og traditionelle Linux-containervirtualiseringsteknologier baseret på brugen af ​​cgroups, namespaces, Seccomp og SELinux. PulseAudio bruges til at udsende lyd. I dette tilfælde kan isolation deaktiveres, som bruges af udviklerne af mange populære pakker til at få fuld adgang til filsystemet og alle enheder i systemet. For eksempel kommer GIMP, VSCodium, PyCharm, Octave, Inkscape, Audacity og VLC med en begrænset isolationstilstand, der giver fuld adgang til hjemmebiblioteket. Hvis pakker med adgang til hjemmemappen kompromitteres, på trods af tilstedeværelsen af ​​"sandboxed"-etiketten i pakkebeskrivelsen, behøver angriberen kun at ændre ~/.bashrc-filen for at udføre sin kode. Et særskilt problem er kontrollen med ændringer af pakker og tillid til pakkebyggere, som ofte ikke er forbundet med hovedprojektet eller distributionerne.

Kilde: opennet.ru

Tilføj en kommentar