Notes de version 0.9.4 bêta
Date de publication : 12 septembre 2026
Version précédente : 0.9.3 Beta (21 mai 2026)
Espaces de noms utilisateur non privilégiés : restreints, pas désactivés
Section intitulée « Espaces de noms utilisateur non privilégiés : restreints, pas désactivés »Arch a retiré bubblewrap-suid en septembre 2026. Ditana s’appuyait sur ce paquet pour que les bacs à sable continuent de fonctionner alors que les espaces de noms utilisateur non privilégiés restaient désactivés, si bien que son retrait a cassé simultanément les deux moitiés de ce dispositif – et comme le programme d’installation récupère sa configuration à l’exécution, ce retrait a également cassé les installations à partir du support 0.9.3 déjà publié, et pas seulement celles nouvellement créées.
Il n’existait aucun remplaçant vers lequel migrer. Le projet amont a supprimé la prise en charge de setuid dans bubblewrap 0.12.0, un jour après que la 0.11.2 a corrigé la CVE-2026-41163, une élévation de privilèges qui n’existait que dans ce mode, et la branche 0.11.x mise à la disposition de quiconque en avait encore besoin n’a jamais été adoptée par personne.
Le dispositif est donc désormais inversé. Plutôt que de désactiver les espaces de noms utilisateur pour tous et d’en exempter un seul binaire, Ditana les autorise exécutable par exécutable. Un programme BPF attaché au crochet userns_create du noyau refuse un espace de noms à tout ce qui n’a pas été déclaré, et la déclaration se trouve dans la configuration, à côté du paquet qui en a besoin :
- name="flatpak" default-value=#true { arch-packages "flatpak" userns-allow "/usr/bin/bwrap" }Un point essentiel, car il détermine l’issue en cas d’erreur : un crochet de ce type ne peut que refuser, jamais accorder. Le sysctl qui désactivait auparavant les espaces de noms utilisateur doit être relevé pour que le gardien ait quelque chose sur quoi agir, et il n’est relevé que par le service qui a déjà chargé et attaché le programme. Une machine qui ne peut pas le charger garde les espaces de noms utilisateur entièrement désactivés. L’échec vous coûte vos bacs à sable, mais jamais votre protection.
Le gardien est un paquet distinct, ditana-userns-guard, installé avec l’option System Hardening qui s’appelait auparavant « Disable unprivileged user namespaces ».
LibreWolf provient désormais d’Arch
Section intitulée « LibreWolf provient désormais d’Arch »LibreWolf provient désormais des dépôts d’Arch plutôt que de Flathub, conformément à l’ordre de préférence qui place un paquet natif en premier. Brave reste disponible via l’AUR ; la justification est détaillée sur la page AUR ou Flatpak.
Chaque valeur sysctl est déclarée sous forme de données
Section intitulée « Chaque valeur sysctl est déclarée sous forme de données »Chaque valeur sysctl qu’écrit le programme d’installation est désormais déclarée sous forme de données au lieu d’être assemblée sous forme de texte shell. Deux paramètres qui écrivent la même clé avec des valeurs différentes arrêtent l’installation et sont tous deux nommés. Auparavant, les deux lignes étaient écrites et la dernière l’emportait silencieusement.
Installation sans surveillance
Section intitulée « Installation sans surveillance »Une installation peut désormais s’exécuter sans que personne ne soit présent au clavier. Un fichier de réponses fournit à l’avance ce que le programme d’installation demanderait normalement, et il se trouve sur un petit lecteur de configuration que le programme d’installation découvre de lui-même – exactement le dispositif qu’un hébergeur utiliserait pour installer Ditana via PXE. Aucune frappe de touche n’est simulée où que ce soit : le mécanisme repose sur le fait que le programme d’installation lit ses réponses au lieu de les demander, et c’est pourquoi il fonctionne pour un hébergeur et pas seulement pour un test.
Le mot de passe du compte est lu dans le fichier de réponses sous forme de hachage, jamais en clair. Un fichier d’exemple est disponible dans le dépôt du programme d’installation, et le mécanisme y est entièrement documenté.
Une réponse qui ne peut pas prendre effet arrête l’installation au lieu d’être ignorée en silence : un paramètre que cette machine ne propose pas, et un paramètre qu’une expression par défaut écraserait à nouveau, sont tous deux refusés nommément, avec la condition qui les rend impossibles. Et comme personne ne regarde l’écran, une exécution qui s’arrête écrit sa cause sur le premier port série, chaque ligne portant le marqueur DITANA-AUTOINSTALL-ABORT:, de sorte qu’un système de provisionnement qui lit la console apprend la raison pendant que la machine est encore en marche, au lieu d’attendre dans le silence. Si la console se trouve ailleurs, la ligne de commande du noyau l’indique.
C’est aussi ce que Ditana utilise pour elle-même. Chaque nuit, la machine de compilation installe le dépôt qu’elle vient de compiler dans une machine virtuelle, sans surveillance, et les paquets ne sont publiés que si le système installé démarre et répond par lui-même.
Consultez docs/unattended-installation.md.
ZFS sur le support d’installation
Section intitulée « ZFS sur le support d’installation »Le support live démarrait un noyau dépourvu du module ZFS, ce qui faisait échouer une installation ZFS sur du matériel où elle réussissait auparavant. Les paquets ZFS sont désormais fournis via pacstrap et l’initramfs est reconstruit ensuite, et zfsbootmenu est ajouté par le crochet qui en est responsable plutôt que par un second chemin susceptible d’entrer en conflit avec lui. Le chemin de démarrage de repli UEFI était erroné et a été corrigé.
Impression
Section intitulée « Impression »La prise en charge des imprimantes est complète. mDNS est ouvert dans firewalld et avahi-daemon est activé, si bien qu’une imprimante réseau est détectée au lieu d’être saisie à la main.
Matériel
Section intitulée « Matériel »Sur certaines machines, le micrologiciel laisse le processeur dans son état d’inactivité le moins profond après une mise en veille, ce qui consomme de l’énergie aussi longtemps que la machine reste allumée. Ditana détecte désormais ce cas et le contourne.
Une nouvelle option lie les réponses ARP à l’interface qui a reçu la requête. Sur une machine dotée de plus d’une interface dans le même sous-réseau, le noyau répond sinon depuis l’interface de son choix, ce qui perturbe les commutateurs et certaines configurations d’équilibrage de charge.
La détection graphique vérifie désormais si le GPU fonctionne sous Wayland plutôt que s’il accélère quoi que ce soit, ce qui est la question dont dépendent réellement les choix de bureau.
L’option Extended ZRAM Overcommit porte la taille virtuelle du swap compressé en RAM de 100 % à 175 % de la RAM physique et l’effort de zstd du niveau 3 au niveau 6, si bien qu’une machine contient environ 1,75 fois sa RAM sous forme compressée avant de recourir à la partition d’échange sur le disque. La latence de rechargement des pages reste la même, car zstd décompresse à la même vitesse quel que soit le coût du niveau. La valeur par défaut reste inchangée.
Le support d’installation lui-même
Section intitulée « Le support d’installation lui-même »L’image ISO est construite avec archiso 90. b43-firmware en a été retiré : ce paquet faisait entrer le noyau principal dans le support, à côté de celui que démarre Ditana. Le processus de construction a été rendu plus strict – rien de ce qui est copié dans le support ne peut désormais suivre un lien symbolique qui renvoie vers le système live, les permissions de ce qui y est placé sont déclarées au lieu d’être héritées, et plusieurs gigaoctets de fichiers intermédiaires sont stockés sur un disque au lieu d’un tmpfs.
Le support contient l’état versionné, et rien de plus : un fichier qui se trouve dans l’arbre de travail et qu’aucune règle du dépôt ne déclare arrête une construction signée, puisque tout ce qui se trouve sous le répertoire airootfs du profil entre dans l’image. Le système installé consigne ensuite son origine, sous la forme de BUILD_ID et VERSION_CODENAME dans /usr/lib/os-release : quel support l’a construit, et quel état de configuration ce support contenait.
Des compilations que vous pouvez vérifier
Section intitulée « Des compilations que vous pouvez vérifier »Chaque paquet que fournit Ditana est recompilé à partir de sa recette amont, signé et publié uniquement sous forme d’ensemble complet : si la compilation d’un paquet échoue ou si ses sources ne peuvent pas être vérifiées, rien du tout n’est publié. Depuis la version 0.9.3, ce processus est devenu visible. Chaque exécution est consignée et rendue publique, y compris les exécutions qui n’ont rien publié, et chaque paquet recompilé renvoie au journal de sa propre compilation.
Deux éléments ont été ajoutés depuis. Chaque modification introduite par une recette amont est classée avant toute compilation, et tout ce qui n’est pas sûr par construction arrête toute l’exécution pour qu’une personne l’examine – l’AUR a été la cible d’une attaque active de la chaîne d’approvisionnement, et Ditana recompile les recettes de l’AUR dans un dépôt auquel ses utilisateurs font confiance par la configuration des signatures de pacman. Et un dépôt qui se compile et se signe sans problème peut malgré tout être un dépôt à partir duquel personne ne peut installer ; c’est pourquoi il est installé dans une machine virtuelle avant d’être publié.
La chaîne de compilation sur laquelle repose tout cela est désormais publique elle aussi. Elle est plus ancienne que Ditana : elle a commencé vers 2023 comme un unique script shell et n’a jamais été destinée à être vue par quelqu’un d’autre. Elle est publiée parce que les affirmations de la page des compilations valent ce que valent leurs preuves, et qu’elle fait partie de ces preuves. Elle se trouve sur github.com/acrion/ditana-build, et les exécutions qu’elle consigne se trouvent sur ditana.org/builds.
Les paquets sont signés avec une sous-clé de signature dédiée au lieu de la clé principale. Une sous-clé peut être révoquée et remplacée indépendamment, et elle ne peut pas certifier d’autres clés. Aucune action n’est nécessaire à ce sujet : le trousseau qui la contient a été livré en août et a depuis longtemps été récupéré.
Mise à niveau depuis la 0.9.3
Section intitulée « Mise à niveau depuis la 0.9.3 »Les installations effectuées avec le support 0.9.3 continuent de fonctionner, à un seul cas près, qui doit être résolu manuellement. bubblewrap-suid n’existe plus, la prochaine mise à jour du système le remplace donc, et Flatpak et Bubblejail cessent de fonctionner sur une machine où les espaces de noms utilisateur non privilégiés sont désactivés. Brave et les autres applications de l’AUR ne sont pas concernés.
Le remède est le gardien décrit plus haut :
sudo pacman -Syu ditana-userns-guardecho /usr/bin/bwrap | sudo tee /etc/ditana/userns-allow.confsudo systemctl enable --now ditana-userns-guard.serviceUn chemin absolu par ligne ; # introduit un commentaire. Le service refuse de relever le sysctl s’il n’a pas d’abord chargé et attaché le programme, de sorte qu’une machine sur laquelle il ne peut pas s’exécuter reste exactement aussi verrouillée qu’avant.
Un support plus ancien ne peut plus du tout installer. Le programme d’installation récupère sa configuration au moment de son exécution, si bien qu’une clé USB 0.9.3 cherche des paquets que son propre dépôt ne peut plus fournir, et s’arrête. Écrivez-y l’image actuelle.
Une nouvelle installation à partir du support 0.9.4 n’a besoin de rien de tout cela.
Cette traduction a été réalisée par une machine. Les lecteurs l’améliorent sur Weblate.