Paglabas ng Flatpak 1.14.0 na self-contained package system

Ang isang bagong matatag na sangay ng Flatpak 1.14 toolkit ay nai-publish, na nagbibigay ng isang sistema para sa pagbuo ng mga self-contained na pakete na hindi nakatali sa mga partikular na pamamahagi ng Linux at tumatakbo sa isang espesyal na lalagyan na naghihiwalay sa application mula sa iba pang bahagi ng system. Ang suporta para sa pagpapatakbo ng mga pakete ng Flatpak ay ibinibigay para sa Arch Linux, CentOS, Debian, Fedora, Gentoo, Mageia, Linux Mint, Alt Linux at Ubuntu. Ang mga pakete ng Flatpak ay kasama sa repositoryo ng Fedora at sinusuportahan ng katutubong GNOME application manager.

Mga pangunahing inobasyon sa sangay ng Flatpak 1.14:

  • Posibleng gumawa ng direktoryo para sa mga file sa state (.local/state) at itakda ang XDG_STATE_HOME environment variable na tumuturo sa direktoryo na ito.
  • Nagdagdag ng mga conditional na pagsusuri ng form na "have-kernel-module-name" upang matukoy ang pagkakaroon ng kernel modules (isang unibersal na analogue ng dati nang iminungkahing have-intel-gpu check, sa halip na ang expression na "have-kernel-module-i915 ” ay maaari nang gamitin).
  • Ang command na β€œflatpak document-unexport β€”doc-id=…” ay ipinatupad.
  • Ibinibigay ang pag-export ng metadata ng Appstream para gamitin sa pangunahing kapaligiran.
  • Nagdagdag ng mga panuntunan sa pagkumpleto ng utos ng flatpak para sa shell ng Isda
  • Pinapayagan ang network access sa mga serbisyo ng X11 at PulseAudio (kung idinagdag ang naaangkop na mga setting).
  • Ang pangunahing sangay sa repositoryo ng Git ay pinalitan ng pangalan mula sa "master" sa "pangunahing", dahil ang salitang "master" ay kamakailang itinuturing na hindi tama sa pulitika.
  • Ang mga script ng paglulunsad ay muling isinusulat ngayon kung ang pangalan ay pinalitan ng pangalan.
  • Idinagdag ang "--include-sdk" at "--include-debug" na mga opsyon sa install command para i-install ang SDK at debuginfo file.
  • Nagdagdag ng suporta para sa parameter na "DeploySideloadCollectionID" sa flatpakref at flatpakrepo file. Kapag nakatakda, itatakda ang collection ID kapag nagdaragdag ng remote na repository, at hindi pagkatapos i-load ang metadata.
  • Pinayagan ang paggawa ng mga nested sandbox environment para sa mga humahawak sa mga session na may magkahiwalay na pangalan ng MPRIS (Media Player Remote Interfacing Specification).
  • Ang mga command line utility ay nagbibigay na ngayon ng impormasyon tungkol sa paggamit ng mga lumang runtime extension.
  • Ang utos sa pag-uninstall ay nagpapatupad ng kahilingan sa pagkumpirma bago alisin ang runtime o runtime na mga extension na ginagamit pa rin.
  • Sinusuportahan na ngayon ng mga command tulad ng "flatpak run" ang opsyong "--socket=gpg-agent".
  • Ang isang kahinaan ay naayos sa libostree na posibleng magpapahintulot sa isang user na magtanggal ng mga arbitrary na file sa system sa pamamagitan ng pagmamanipula ng flatpak-system-helper handler (nagpapadala ng kahilingan sa pagtanggal na may espesyal na format na pangalan ng sangay). Lumalabas lang ang problema sa mga mas lumang bersyon ng Flatpak at libostree na inilabas bago ang 2018 (< 0.10.2) at hindi nakakaapekto sa mga kasalukuyang release.

Paalalahanan ka namin na ang Flatpak ay nagpapahintulot sa mga developer ng application na pasimplehin ang pamamahagi ng kanilang mga programa na hindi kasama sa mga karaniwang repositoryo ng pamamahagi sa pamamagitan ng paghahanda ng isang unibersal na lalagyan nang hindi gumagawa ng hiwalay na mga asembliya para sa bawat pamamahagi. Para sa mga gumagamit na may kamalayan sa seguridad, pinapayagan ka ng Flatpak na magpatakbo ng isang kaduda-dudang application sa isang lalagyan, na nagbibigay ng access lamang sa mga function ng network at mga file ng user na nauugnay sa application. Para sa mga user na interesado sa mga bagong produkto, pinapayagan ka ng Flatpak na i-install ang pinakabagong pagsubok at mga stable na release ng mga application nang hindi na kailangang gumawa ng mga pagbabago sa system. Halimbawa, ang mga pakete ng Flatpak ay binuo para sa LibreOffice, Midori, GIMP, Inkscape, Kdenlive, Steam, 0 AD, Visual Studio Code, VLC, Slack, Skype, Telegram Desktop, Android Studio, atbp.

Upang bawasan ang laki ng package, kasama lang dito ang mga dependency na tukoy sa application, at ang mga pangunahing library ng system at graphics (mga library ng GTK, Qt, GNOME at KDE, atbp.) ay idinisenyo bilang mga plug-in na karaniwang runtime na kapaligiran. Ang pangunahing pagkakaiba sa pagitan ng Flatpak at Snap ay ang Snap ay gumagamit ng mga bahagi ng pangunahing kapaligiran ng system at paghihiwalay batay sa pag-filter ng mga tawag sa system, habang ang Flatpak ay gumagawa ng isang lalagyan na hiwalay sa system at nagpapatakbo ng malalaking runtime set, na hindi nagbibigay ng mga pakete bilang mga dependency, ngunit karaniwang mga kapaligiran ng system (halimbawa, lahat ng mga aklatan na kailangan para sa pagpapatakbo ng mga programang GNOME o KDE).

Bilang karagdagan sa karaniwang kapaligiran ng system (runtime), na naka-install sa pamamagitan ng isang espesyal na imbakan, ang mga karagdagang dependency (bundle) na kinakailangan para sa pagpapatakbo ng application ay ibinibigay. Sa kabuuan, ang runtime at bundle ang bumubuo sa pagpuno ng container, sa kabila ng katotohanan na ang runtime ay naka-install nang hiwalay at nakatali sa ilang mga container nang sabay-sabay, na nagbibigay-daan sa iyong maiwasan ang pagdoble ng mga system file na karaniwan sa mga container. Ang isang system ay maaaring magkaroon ng ilang magkakaibang runtime na naka-install (GNOME, KDE) o ilang bersyon ng parehong runtime (GNOME 3.40, GNOME 3.42). Ang isang container na may application bilang dependency ay gumagamit ng isang binding lamang sa isang partikular na runtime, nang hindi isinasaalang-alang ang mga indibidwal na package na bumubuo sa runtime. Ang lahat ng nawawalang elemento ay direktang nakabalot sa application. Kapag nabuo ang isang lalagyan, ang mga nilalaman ng runtime ay ini-mount bilang ang /usr partition, at ang bundle ay naka-mount sa direktoryo ng /app.

Ang runtime at application container ay binuo gamit ang OSTree technology, kung saan ang imahe ay atomically updated mula sa isang Git-like repository, na nagbibigay-daan sa mga version control method na mailapat sa mga bahagi ng pamamahagi (halimbawa, maaari mong mabilis na i-roll back ang system sa isang nakaraang estado). Ang mga RPM package ay isinasalin sa OSTree repository gamit ang isang espesyal na rpm-ostree layer. Ang hiwalay na pag-install at pag-update ng mga pakete sa loob ng kapaligiran sa pagtatrabaho ay hindi suportado; ang system ay na-update hindi sa antas ng mga indibidwal na bahagi, ngunit sa kabuuan, atomically nagbabago ang estado nito. Nagbibigay ng mga tool upang ilapat ang mga update nang paunti-unti, na inaalis ang pangangailangan na ganap na palitan ang larawan sa bawat update.

Ang nabuong nakahiwalay na kapaligiran ay ganap na independiyente sa pamamahagi na ginamit at, na may wastong mga setting ng package, ay walang access sa mga file at proseso ng user o ng pangunahing system, ay hindi direktang ma-access ang kagamitan, maliban sa output sa pamamagitan ng DRI, at mga tawag sa network subsystem. Ang graphics output at input organization ay ipinapatupad gamit ang Wayland protocol o sa pamamagitan ng X11 socket forwarding. Ang pakikipag-ugnayan sa panlabas na kapaligiran ay batay sa DBus messaging system at isang espesyal na Portals API.

Para sa paghihiwalay, ginagamit ang Bubblewrap layer at tradisyonal na Linux container virtualization na teknolohiya, batay sa paggamit ng mga cgroup, namespace, Seccomp at SELinux. Ginagamit ang PulseAudio upang mag-output ng tunog. Sa kasong ito, maaaring hindi paganahin ang paghihiwalay, na ginagamit ng mga developer ng maraming sikat na pakete upang makakuha ng ganap na access sa file system at lahat ng device sa system. Halimbawa, ang GIMP, VSCodium, PyCharm, Octave, Inkscape, Audacity, at VLC ay may limitadong isolation mode na nag-iiwan ng ganap na access sa home directory. Kung ang mga package na may access sa home directory ay nakompromiso, sa kabila ng pagkakaroon ng "sandboxed" na label sa paglalarawan ng package, kailangan lang ng attacker na baguhin ang ~/.bashrc file upang maisagawa ang kanyang code. Ang isang hiwalay na isyu ay ang kontrol ng mga pagbabago sa mga pakete at pagtitiwala sa mga tagabuo ng package, na kadalasang hindi nauugnay sa pangunahing proyekto o mga pamamahagi.

Pinagmulan: opennet.ru

Magdagdag ng komento