È stata pubblicata una nuova versione stabile del toolkit Flatpak 1.14, che fornisce un sistema per la creazione di pacchetti autonomi, non legati a specifiche distribuzioni Linux, eseguiti in un contenitore speciale che isola l'applicazione dal resto del sistema. Il supporto per l'esecuzione dei pacchetti Flatpak è garantito per Arch Linux, CentOS, Debian, Fedora, Gentoo, Mageia, Linux Mint, Alt Linux e Ubuntu. I pacchetti Flatpak sono inclusi nel repository di Fedora e sono supportati dall'app di gestione delle applicazioni GNOME.
Novità principali nella versione Flatpak 1.14:
- È stata garantita la creazione di una directory per i file nello stato (.local/state) e l'impostazione della variabile d'ambiente XDG_STATE_HOME che punta a questa directory.
- Aggiunti controlli condizionali del tipo "have-kernel-module-nome" per determinare la presenza di moduli del kernel (un'alternativa universale al precedente controllo have-intel-gpu, mentre ora si può usare l'espressione "have-kernel-module-i915").
- Implementato il comando "flatpak document-unexport —doc-id=…".
- È stato garantito l'esportazione dei metadati Appstream per l'uso nell'ambiente principale.
- Sono state aggiunte regole di completamento automatico dei comandi flatpak per la shell Fish.
- È stato autorizzato l'accesso di rete ai servizi X11 e PulseAudio (aggiungendo le relative impostazioni).
- Il ramo principale nel repository Git è stato rinominato da "master" a "main", poiché la parola "master" è considerata, ultimamente, politicamente scorretta.
- È stata garantita la sovrascrittura degli script di avvio in caso di rinominazione dell'applicazione.
- Nel comando install sono state aggiunte le opzioni "—include-sdk" e "—include-debug" per l'installazione di SDK e file debuginfo.
- Nei file flatpakref e flatpakrepo è stato aggiunto il supporto per il parametro "DeploySideloadCollectionID", in base al quale l'identificativo della collezione sarà impostato durante l'aggiunta del repository remoto e non dopo il caricamento dei metadati.
- È stata autorizzata la creazione di ambienti sandbox annidati per i gestori in sessioni con nomi MPRIS separati (Media Player Remote Interfacing Specification).
- Negli strumenti da linea di comando è stato garantito il rilascio di informazioni sull'uso di extentsioni runtime obsolete.
- Nel comando uninstall è stata implementata una richiesta di conferma prima di rimuovere runtime o estensioni runtime che sono ancora in uso.
- Nei comandi simili a "flatpak run" è stato aggiunto il supporto per l'opzione "—socket=gpg-agent".
- In libostree è stata risolta una vulnerabilità che potrebbe consentire a un utente di eliminare file arbitrari dal sistema tramite manipolazioni con il gestore flatpak-system-helper (inviando una richiesta di eliminazione con un nome di ramo appositamente formattato). Il problema si manifesta solo nelle versioni obsolete di Flatpak e libostree rilasciate prima del 2018 (< 0.10.2) e non interessa le versioni attuali.
Ricordiamo che lo sviluppo di applicazioni Flatpak offre la possibilità di semplificare la distribuzione dei propri programmi, che non rientrano nei repository ufficiali delle distribuzioni, preparando un unico contenitore universale senza dover creare build separate per ogni distribuzione. Per gli utenti attenti alla sicurezza, Flatpak consente di eseguire applicazioni sospette all'interno di un contenitore, fornendo accesso solo alle funzioni di rete e ai file dell'utente collegati all'applicazione. Per gli utenti interessati alle novità, Flatpak permette di installare le versioni più recenti di applicazioni sia in fase di test che stabili, senza necessità di modificare il sistema. Ad esempio, i pacchetti Flatpak vengono creati per LibreOffice, Midori, GIMP, Inkscape, Kdenlive, Steam, 0 A.D., Visual Studio Code, VLC, Slack, Skype, Telegram Desktop, Android Studio, ecc.
Per ridurre la dimensione del pacchetto, include solo le dipendenze specifiche per l'applicazione, mentre le librerie di base di sistema e grafiche (GTK, Qt, librerie GNOME e KDE, ecc.) sono organizzate come ambienti runtime standard collegabili. La principale differenza tra Flatpak e Snap è che Snap utilizza componenti dell'ambiente di sistema principale e un'isolamento basato sulla filtrazione delle chiamate di sistema, mentre Flatpak crea un contenitore separato dal sistema e opera con grandi insiemi di runtime, fornendo come dipendenze non pacchetti, ma ambienti di sistema standard (ad esempio, tutte le librerie necessarie per l'esecuzione dei programmi GNOME o KDE).
Oltre all'ambiente di runtime standard (runtime), installato tramite un repository speciale, vengono fornite dipendenze aggiuntive (bundle) necessarie per il funzionamento dell'applicazione. Insieme, runtime e bundle costituiscono il contenuto del container, con la specifica che il runtime viene installato separatamente e può essere collegato a più container, evitando così la duplicazione di file di sistema comuni ai container. In un sistema possono essere installati diversi runtime (GNOME, KDE) o più versioni di uno stesso runtime (GNOME 3.40, GNOME 3.42). Un container con un'applicazione come dipendenza utilizza il collegamento solo a uno specifico runtime, senza prendere in considerazione i singoli pacchetti che compongono il runtime. Tutti gli elementi mancanti vengono confezionati direttamente con l'applicazione. Durante la creazione del container, il contenuto del runtime è montato come la partizione /usr, mentre il bundle è montato nella directory /app.
Il contenuto del runtime e dei container delle applicazioni è creato utilizzando la tecnologia OSTree, che consente di aggiornare in modo atomico un'immagine da un repository simile a Git, consentendo di applicare metodi di controllo delle versioni ai componenti della distribuzione (ad esempio, è possibile ripristinare rapidamente il sistema a uno stato precedente). I pacchetti RPM vengono tradotti nel repository OSTree tramite uno strato speciale chiamato rpm-ostree. L'installazione e l'aggiornamento di pacchetti all'interno dell'ambiente di lavoro non sono supportati; il sistema viene aggiornato non a livello di singoli componenti, ma completamente, cambiando in modo atomico il proprio stato. Sono fornuti strumenti per l'applicazione incrementale degli aggiornamenti, eliminando la necessità di una sostituzione completa dell'immagine ad ogni aggiornamento.
L'ambiente isolato creato è completamente indipendente dalla distribuzione utilizzata e, con le impostazioni appropriate del pacchetto, non ha accesso ai file e ai processi dell'utente o del sistema principale, non può accedere direttamente all'hardware, tranne che per l'output tramite DRI, e alle richieste al sottosistema di rete. L'output grafico e l'organizzazione dell'input vengono realizzati tramite il protocollo Wayland o attraverso il passaggio della socket X11. L'interazione con l'ambiente esterno è basata sul sistema di messaggistica DBus e su un'API speciale chiamata Portals.
Per l'isolamento viene utilizzato un livello intermedio Bubblewrap e le tradizionali tecnologie di virtualizzazione dei contenitori di Linux, basate su cgroups, spazi dei nomi (namespaces), Seccomp e SELinux. Per l'uscita audio viene utilizzato PulseAudio. Tuttavia, l'isolamento può essere disabilitato, un'opzione usata da molti sviluppatori di pacchetti popolari per ottenere accesso completo al file system e a tutti i dispositivi nel sistema. Ad esempio, alcuni pacchetti GIMP, VSCodium, PyCharm, Octave, Inkscape, Audacity e VLC vengono forniti con una modalità di isolamento limitata che consente l'accesso completo alla directory home. In caso di compromissione dei pacchetti con accesso alla directory home, nonostante la presenza dell'etichetta "sandboxed" nella descrizione del pacchetto, un attaccante deve semplicemente modificare il file ~/ .bashrc per eseguire il proprio codice. Un'altra questione è il controllo delle modifiche ai pacchetti e la fiducia nei costruttori di pacchetti, che spesso non sono legati direttamente al progetto principale o alle distribuzioni.
Fonte: opennet.ru
