Flatpak corregge le subsandbox e riorganizza le dipendenze Meson

🐧 Novità principali

• Flatpak corregge l’avvio delle subsandbox quando un’app è configurata con restrizioni D-Bus `–no-talk-name` o `–system-no-talk-name`.
• libglnx e variant-schema-compiler passano da git subtree a Meson wrap subprojects, semplificando la gestione delle dipendenze durante la build.
• Il changelog upstream colloca queste modifiche in Flatpak 1.19.1, ancora non rilasciata, non in una release 1.18.3 già disponibile.

Flatpak prepara un nuovo aggiornamento correttivo concentrato soprattutto sulla stabilità del sandboxing e sulla manutenzione del sistema di build. Il cambiamento più interessante riguarda flatpak-spawn, utilizzato dalle applicazioni per creare processi all’interno di una subsandbox: in alcune configurazioni restrittive D-Bus l’avvio poteva fallire quando l’app principale era stata lanciata con --no-talk-name o --system-no-talk-name. In parallelo il progetto modifica la gestione di alcune dipendenze interne passando a Meson wrap subprojects. Non è un aggiornamento che cambia l’esperienza visibile dell’utente, ma interviene su due aree molto sensibili per Flatpak: isolamento dei processi e riproducibilità delle build.

Flatpak-spawn torna a funzionare con policy D-Bus più restrittive

Il fix principale riguarda l’avvio delle subsandbox tramite flatpak-spawn. Flatpak permette infatti a un’applicazione già confinata di creare ulteriori processi in ambienti isolati, meccanismo utile per browser, IDE e software che separano componenti o workload differenti. Il problema emergeva quando l’applicazione principale era stata configurata con regole D-Bus particolarmente rigide attraverso --no-talk-name o --system-no-talk-name. In queste condizioni, il processo figlio poteva non riuscire ad avviarsi correttamente. Il changelog upstream indica esplicitamente la correzione di questo percorso. La modifica è tecnica ma rilevante perché Flatpak costruisce gran parte del proprio modello di isolamento proprio sulla combinazione tra namespace, Bubblewrap, policy D-Bus e portali. Flatpak utilizza Bubblewrap per creare il filesystem e i namespace della sandbox, mentre l’accesso ai servizi esterni viene mediato attraverso permessi e interfacce controllate.

Leggi anche: KDE Plasma 6.7.5 corregge Discover, HDR, Flatpak e diversi crash

Meson wrap sostituisce i git subtree per due componenti interni

Il secondo cambiamento riguarda il sistema di build. libglnx e variant-schema-compiler diventano Meson wrap subprojects, abbandonando il precedente modello basato sui git subtree. Per gli utenti finali la modifica è invisibile, ma per maintainer e distribuzioni riduce l’attrito nella gestione delle dipendenze. I wrap Meson permettono al progetto di dichiarare e recuperare componenti esterni direttamente dal sistema di build, oppure di utilizzare versioni installate sul sistema quando la distribuzione preferisce evitare download durante la compilazione. Il modello è già utilizzato per dipendenze come Bubblewrap e xdg-dbus-proxy. Le tarball ufficiali dovrebbero includere versioni coerenti dei subproject, mentre chi compila direttamente da Git in ambienti privi di accesso automatico alle dipendenze dovrà configurare Meson di conseguenza.

L’aggiornamento include anche correzioni di robustezza e sicurezza

Il ramo in sviluppo contiene inoltre aggiornamenti ai Meson wrap di Bubblewrap 0.12.0 e xdg-dbus-proxy 0.1.8, collegati rispettivamente a CVE-2026-87766 e CVE-2026-93676. Il changelog segnala anche fix per crash del system helper, gestione dei file descriptor nei portal, problemi con openat2, output non UTF-8 e validazione delle strutture GVariant. Il contesto è significativo perché Flatpak 1.19.0 aveva già corretto vulnerabilità più pesanti, comprese una sandbox escape con accesso al filesystem host e una privilege escalation locale attraverso revokefs. Il nuovo ciclo appare quindi più orientato alla stabilizzazione del ramo rispetto all’introduzione di grandi funzionalità.

Continua con:

KDE Plasma 6.7.5 corregge Discover, HDR, Flatpak e diversi crash

Flatpak lavora sul punto più delicato: rendere il sandboxing prevedibile

Questo ciclo mostra bene il tipo di lavoro necessario a una piattaforma di distribuzione come Flatpak. Il sandboxing non dipende da un singolo componente, ma dall’interazione tra namespace, Bubblewrap, D-Bus proxy, portali, helper e policy definite dall’applicazione. Quando uno di questi livelli non interpreta correttamente una restrizione, il risultato può essere un processo che non parte oppure, nei casi peggiori, una riduzione dell’isolamento previsto. Il fix a flatpak-spawn non introduce quindi una nuova funzione appariscente: rende più coerente il comportamento delle subsandbox proprio quando le policy diventano più restrittive. È un intervento meno visibile di un nuovo comando o di un cambiamento grafico, ma è esattamente il tipo di manutenzione che Flatpak deve continuare a fare se vuole restare uno dei pilastri della distribuzione applicativa sui desktop Linux.