Note di rilascio della versione 0.9.4 Beta
Data di rilascio: 12 settembre 2026
Versione precedente: 0.9.3 Beta (21 maggio 2026)
User namespace non privilegiati: limitati, non disattivati
Sezione intitolata «User namespace non privilegiati: limitati, non disattivati»A settembre 2026 Arch ha rimosso bubblewrap-suid. Ditana vi faceva affidamento per mantenere funzionanti le sandbox mentre gli user namespace (spazi dei nomi utente) non privilegiati restavano disattivati, per cui la sua rimozione ha compromesso contemporaneamente entrambe le metà di questa configurazione – e poiché il programma di installazione scarica la propria configurazione al momento dell’esecuzione, ha compromesso anche le installazioni dal supporto della versione 0.9.3, già rilasciato, e non solo quelle appena create.
Non esisteva un sostituto verso cui migrare. Il progetto upstream ha rimosso il supporto setuid in bubblewrap 0.12.0, un giorno dopo che la 0.11.2 aveva corretto CVE-2026-41163, un’escalation dei privilegi che esisteva unicamente in quella modalità, e il ramo 0.11.x, messo a disposizione di chi ne avesse ancora bisogno, non è mai stato adottato da nessuno.
Per questo ora l’approccio è capovolto. Anziché disattivare gli user namespace per tutti ed esentarne un singolo binario, Ditana li consente eseguibile per eseguibile. Un programma BPF agganciato all’hook userns_create del kernel nega un namespace a tutto ciò che non è stato dichiarato, e la dichiarazione si trova nella configurazione accanto al pacchetto che ne ha bisogno:
- name="flatpak" default-value=#true { arch-packages "flatpak" userns-allow "/usr/bin/bwrap" }Un punto essenziale, perché determina l’esito in caso di errore: un hook di questo tipo può soltanto negare, mai concedere. Il sysctl che in precedenza disattivava gli user namespace deve essere innalzato perché il meccanismo di protezione abbia qualcosa su cui agire, e viene innalzato soltanto dal servizio che ha già caricato e agganciato il programma. Una macchina che non riesce a caricarlo mantiene gli user namespace completamente disattivati. In caso di errore perdete le sandbox, ma mai la protezione.
Il meccanismo di protezione è un pacchetto separato, ditana-userns-guard, installato insieme all’opzione System Hardening, che in precedenza si chiamava «Disable unprivileged user namespaces».
LibreWolf ora proviene da Arch
Sezione intitolata «LibreWolf ora proviene da Arch»LibreWolf proviene ora dai repository di Arch anziché da Flathub, conformemente all’ordine di preferenza che mette al primo posto un pacchetto nativo. Brave continua a essere disponibile tramite l’AUR; le motivazioni sono illustrate nella pagina AUR o Flatpak.
Ogni valore sysctl è dichiarato come dati
Sezione intitolata «Ogni valore sysctl è dichiarato come dati»Ogni valore sysctl scritto dal programma di installazione è ora dichiarato come dati anziché composto come testo di shell. Due impostazioni che scrivono la stessa chiave con valori diversi interrompono l’installazione e vengono indicate entrambe per nome. In precedenza venivano scritte entrambe le righe e l’ultima prevaleva senza alcun avviso.
Installazione non presidiata
Sezione intitolata «Installazione non presidiata»Un’installazione può ora svolgersi senza che nessuno sia presente alla tastiera. Un file di risposte fornisce in anticipo ciò che il programma di installazione chiederebbe normalmente, e si trova su una piccola unità di configurazione che il programma di installazione individua autonomamente – esattamente la stessa soluzione che un fornitore di hosting userebbe per installare Ditana tramite PXE. Non viene simulata alcuna pressione di tasti: il meccanismo consiste nel fatto che il programma di installazione legge le proprie risposte anziché richiederle, ed è per questo che funziona per un fornitore e non solo per un test.
La password dell’account viene letta dal file di risposte sotto forma di hash, mai in chiaro. Un file di esempio è disponibile nel repository del programma di installazione, dove il meccanismo è documentato in modo completo.
Una risposta che non può avere effetto interrompe l’installazione anziché essere scartata in silenzio: un’impostazione che questa macchina non offre e una che un’espressione del valore predefinito sovrascriverebbe di nuovo vengono entrambe rifiutate indicandole per nome, insieme alla condizione che le rende impossibili. E poiché nessuno guarda lo schermo, un’esecuzione che si interrompe scrive la propria causa sulla prima porta seriale, con il marcatore DITANA-AUTOINSTALL-ABORT: su ogni riga, in modo che un sistema di provisioning che legge la console ne conosca il motivo mentre la macchina è ancora in funzione, anziché restare in attesa nel silenzio. Se la console si trova altrove, la indica la riga di comando del kernel.
È anche ciò che Ditana usa su sé stessa. Ogni notte l’host di build installa in una macchina virtuale, senza presidio, il repository che ha appena compilato, e i pacchetti vengono rilasciati solo se il sistema installato si avvia e risponde autonomamente.
Consultate docs/unattended-installation.md.
ZFS sul supporto di installazione
Sezione intitolata «ZFS sul supporto di installazione»Il supporto live avviava un kernel privo del modulo ZFS, per cui un’installazione ZFS non riusciva su hardware su cui in precedenza era riuscita. I pacchetti ZFS vengono ora forniti tramite pacstrap e l’immagine initramfs viene poi rigenerata, e zfsbootmenu viene aggiunto dall’hook responsabile anziché tramite un secondo percorso che potrebbe entrare in conflitto con esso. Il percorso di avvio di ripiego UEFI era errato ed è stato corretto.
Il supporto per le stampanti è completo. mDNS è aperto in firewalld e avahi-daemon è abilitato, per cui una stampante di rete viene rilevata anziché digitata a mano.
Hardware
Sezione intitolata «Hardware»Su alcune macchine il firmware lascia il processore nel suo stato di inattività meno profondo dopo una sospensione, il che consuma energia per tutto il tempo in cui la macchina resta accesa. Ditana ora lo rileva e lo aggira.
Una nuova opzione vincola le risposte ARP all’interfaccia che ha ricevuto la richiesta. Su una macchina con più di un’interfaccia nella stessa sottorete, altrimenti il kernel risponde da quella che preferisce, il che confonde gli switch e alcune configurazioni di bilanciamento del carico.
Il rilevamento della grafica ora verifica se la GPU funziona con Wayland anziché se accelera qualcosa, ed è questa la domanda da cui dipendono effettivamente le scelte relative al desktop.
Memoria
Sezione intitolata «Memoria»Extended ZRAM Overcommit aumenta la dimensione virtuale dello swap compresso in RAM dal 100 % al 175 % della RAM fisica e lo sforzo di compressione di zstd dal livello 3 al livello 6, per cui una macchina contiene circa 1,75 volte la propria RAM in forma compressa prima di ricorrere alla partizione di swap su disco. La latenza di caricamento delle pagine resta la stessa, perché zstd decomprime alla stessa velocità qualunque sia il costo del livello. L’impostazione predefinita resta invariata.
Il supporto di installazione in sé
Sezione intitolata «Il supporto di installazione in sé»L’ISO viene creata con archiso 90. b43-firmware ne è stato rimosso: il pacchetto portava nel supporto il kernel mainline accanto a quello che Ditana avvia. Il processo di creazione è stato reso più rigoroso – nulla di ciò che viene copiato nel supporto può ora seguire un collegamento simbolico che riporti nel sistema live, i permessi di ciò che vi viene inserito sono dichiarati anziché ereditati, e diversi gigabyte di file intermedi vengono salvati su un disco anziché in un tmpfs.
Il supporto contiene lo stato sottoposto a controllo di versione e nient’altro: un file che si trova nell’albero di lavoro e che nessuna regola del repository dichiara interrompe una build firmata, poiché tutto ciò che si trova sotto la directory airootfs del profilo finisce nell’immagine. Il sistema installato registra poi la propria origine, come BUILD_ID e VERSION_CODENAME in /usr/lib/os-release: da quale supporto è stato creato e quale stato della configurazione conteneva quel supporto.
Build verificabili
Sezione intitolata «Build verificabili»Ogni pacchetto distribuito da Ditana viene ricompilato dalla propria ricetta upstream, firmato e pubblicato solo come insieme completo: se la compilazione di un pacchetto non riesce o se i suoi sorgenti non possono essere verificati, non viene pubblicato nulla. Dalla versione 0.9.3 questo processo è diventato visibile. Ogni esecuzione viene registrata e resa pubblica, comprese quelle che non hanno distribuito nulla, e ogni pacchetto ricompilato rimanda al log della propria build.
Da allora si sono aggiunte due cose. Ogni modifica introdotta da una ricetta upstream viene classificata prima di compilare qualsiasi cosa, e tutto ciò che non è sicuro per costruzione ferma l’intera esecuzione affinché una persona la esamini – l’AUR è stato oggetto di un attacco attivo alla catena di approvvigionamento, e Ditana ricompila le ricette AUR in un repository di cui i suoi utenti si fidano tramite la configurazione delle firme di pacman. Inoltre, un repository che viene compilato e firmato senza problemi può comunque essere un repository che nessuno può usare per installare, per cui viene installato in una macchina virtuale prima di essere rilasciato.
Anche la pipeline su cui si basa tutto questo è ora pubblica. È più vecchia di Ditana: è nata intorno al 2023 come un unico script di shell e non è mai stata pensata per gli occhi di altri. Viene pubblicata perché le affermazioni della pagina delle build valgono quanto valgono le loro prove, e la pipeline fa parte delle prove. Si trova su github.com/acrion/ditana-build, e le esecuzioni che registra si trovano su ditana.org/builds.
I pacchetti vengono firmati con una sottochiave di firma dedicata anziché con la chiave primaria. Una sottochiave può essere revocata e sostituita in modo indipendente e non può certificare altre chiavi. Non dovete fare nulla al riguardo: il portachiavi che la contiene è stato distribuito ad agosto ed è già installato da tempo.
Aggiornare dalla versione 0.9.3
Sezione intitolata «Aggiornare dalla versione 0.9.3»Le installazioni create con il supporto della versione 0.9.3 continuano a funzionare, con un unico caso che va risolto manualmente. bubblewrap-suid non esiste più, per cui il prossimo aggiornamento del sistema lo sostituisce, e Flatpak e Bubblejail smettono di funzionare su una macchina su cui gli user namespace non privilegiati sono disattivati. Brave e le altre applicazioni AUR non sono interessate.
Il rimedio è il meccanismo di protezione descritto sopra:
sudo pacman -Syu ditana-userns-guardecho /usr/bin/bwrap | sudo tee /etc/ditana/userns-allow.confsudo systemctl enable --now ditana-userns-guard.serviceUn percorso assoluto per riga; # introduce un commento. Il servizio si rifiuta di innalzare il sysctl se prima non ha caricato e agganciato il programma, per cui una macchina su cui non può essere eseguito mantiene esattamente le stesse restrizioni di prima.
Un supporto più vecchio non può più installare affatto. Il programma di installazione scarica la propria configurazione al momento dell’esecuzione, per cui una chiavetta USB della versione 0.9.3 cerca pacchetti che il suo stesso repository non può più fornire e si ferma. Scrivete sulla chiavetta l’immagine attuale.
Una nuova installazione dal supporto della versione 0.9.4 non richiede nulla di tutto ciò.
Questa traduzione è stata realizzata automaticamente. I lettori la migliorano su Weblate.