AUR o Flatpak

Ditana supporta i pacchetti nativi di Arch, i pacchetti AUR compilati localmente con paru e le applicazioni Flatpak di Flathub eseguite in una sandbox. L’ordine di priorità è prima i pacchetti nativi, poi Flatpak, infine AUR – e il motivo per andare oltre un pacchetto nativo non è mai che Flatpak offra un’esperienza migliore, ma che non sia disponibile alcun pacchetto nativo.

Quando Flatpak è la scelta migliore

Se Arch stesso non offre un pacchetto, per un’applicazione desktop che dispone di una build mantenuta su Flathub preferite Flatpak all’AUR.

• Isolamento in sandbox. Le applicazioni Flatpak vengono eseguite in una sandbox bubblewrap con accesso limitato al file system e all’IPC. Per i browser, i lettori multimediali e gli altri software esposti a Internet, questo costituisce un vero livello di difesa in profondità.
• Nessun tempo di compilazione. La compilazione dei pacchetti AUR dai sorgenti può richiedere minuti (o ore, per grandi applicazioni come LibreOffice). Le installazioni Flatpak scaricano da Flathub file binari già compilati.
• Nessun rischio legato all’ABI. I pacchetti AUR binari a volte smettono di funzionare quando le librerie di sistema vengono aggiornate e il binario upstream si aspetta un’ABI diversa. I Flatpak includono il proprio runtime e sono al riparo da questo rischio.
• Aggiornamenti prevedibili. Le versioni pubblicate su Flathub sono numerate ed è facile tornare a quella precedente. AUR evolve di continuo, senza coordinamento.

Quando AUR è la scelta migliore

Ci sono tre casi in cui Ditana preferisce – o richiede – AUR anziché Flatpak.

Ditana ricompila e firma già 45 delle ricette AUR di cui ha bisogno, per cui paru -S spesso le risolve dal repository di Ditana anziché dall’AUR. Ognuna di esse è stata classificata prima di essere compilata: una modifica a un URL sorgente, a una funzione di build o a una somma di controllo senza cambio di versione ferma l’intera esecuzione, affinché una persona la esamini. Le ricette che Ditana non include vengono installate da paru direttamente dall’AUR, senza revisione: è questa la differenza di cui tratta il resto della pagina.

Browser basati su Chromium con l’hardening predefinito di Ditana

Ditana non concede gli user namespace (spazi dei nomi utente) non privilegiati a ogni programma. Sono stati alla base di diverse escalation locali dei privilegi rese pubbliche, e delle sedici voci relative al kernel Linux registrate in tre anni nel catalogo Known Exploited Vulnerabilities della CISA, sei sono sfruttabili tramite essi – conteggio effettuato sulla versione 2026.09.04 del catalogo; l’individuazione di quali siano le sei è nostra, per cui conviene verificarla anziché crederci sulla parola. Ditana li consente quindi programma per programma: un programma BPF minimo, agganciato all’hook userns_create del kernel stesso, rifiuta un namespace a qualsiasi eseguibile per il quale nessuna impostazione lo abbia richiesto. bwrap l’ha richiesto, per cui ogni Flatpak crea come di consueto la propria sandbox esterna.

Brave proviene comunque dall’AUR come brave-bin, per due motivi che non hanno nulla a che fare con la sandbox esterna. Il suo Flatpak include zypak, che crea ulteriori namespace a partire da un proprio binario, in profondità all’interno della sandbox, e non è stato verificato se un elenco di eseguibili consentiti si estenda anche a questi. Inoltre, un eseguibile all’interno di un Flatpak viene sostituito da flatpak update, operazione che l’hook incaricato di mantenere sincronizzato l’elenco non vede, per cui l’autorizzazione scadrebbe silenziosamente al successivo aggiornamento.

Il pacchetto AUR brave-bin non ha bisogno di nulla di tutto ciò. Include un proprio programma ausiliario setuid chrome-sandbox e crea la propria sandbox senza alcuno user namespace – motivo per cui questo pacchetto resta al suo posto, anche se la regola antepone Flatpak all’AUR.

Se viene rifiutata una sandbox installata da voi

Se a una sandbox installata da voi viene rifiutato uno user namespace, a rifiutarlo è stato il meccanismo di protezione. Aggiungete l’eseguibile a /etc/ditana/userns-allow.conf, un percorso assoluto per riga, e ricaricate la configurazione:

sudo ditana-userns-guard --reload

sudo ditana-userns-guard --status mostra quanti namespace sono stati consentiti e rifiutati da quando il meccanismo di protezione è stato caricato, ed elenca i programmi respinti, dal più recente, ciascuno con l’utente che lo ha eseguito e il numero di volte. sudo ditana-userns-guard --observe smette di rifiutare e continua a tenere l’elenco, per cui mostra che cosa chiederebbe un programma mentre questo continua a funzionare; sudo ditana-userns-guard riattiva il rifiuto.

Software non disponibile su Flathub

Una parte non trascurabile del software utile per Linux si trova solo su AUR – strumenti di sviluppo di nicchia, driver specifici di un produttore, utilità per l’hardware, caratteri. Per questi, AUR è l’unica opzione, e paru ne rende semplice l’installazione.

Se desiderate partecipare all’ecosistema AUR

Se siete utenti Arch che desiderano seguire i feed dei commit AUR, votare i pacchetti o mantenere propri pacchetti AUR, restare su AUR per le applicazioni di tutti i giorni vi mantiene all’interno di questo circuito.

Come decide Ditana al momento dell’installazione

La configurazione KDL consente a ogni impostazione di dichiarare fianco a fianco arch-packages, flatpak-packages e aur-packages, nonché userns-allow per un eseguibile la cui sandbox necessita di uno user namespace. Quando è disponibile più di una fonte, la scelta viene fatta deliberatamente, pacchetto per pacchetto, con una spiegazione registrata nel relativo file .kdl. Consultate ditana-config per vedere le motivazioni nel loro contesto.

Consiglio pratico: controllare regolarmente i Flatpak installati

I runtime Flatpak si accumulano. Eseguite di tanto in tanto sudo flatpak uninstall --unused per recuperare spazio su disco – e sudo flatpak update per mantenere aggiornate le applicazioni. Entrambe le operazioni sono sicure. Ditana installa i Flatpak nell’installazione di sistema anziché in una per singolo utente, motivo per cui entrambi i comandi richiedono i privilegi di root.