Нотатки щодо випуску 0.9.4 Beta

Дата випуску: 12 вересня 2026 р.
Попередній випуск: 0.9.3 Beta (21 травня 2026 р.)

Непривілейовані простори назв користувача: обмежено, а не вимкнено

У вересні 2026 року Arch вилучив bubblewrap-suid. Ditana покладалася на нього, щоб пісочниці працювали, поки непривілейовані простори назв користувача (user namespaces) залишалися вимкненими, тож його вилучення зламало обидві половини цієї схеми одночасно — а оскільки інсталятор отримує свою конфігурацію під час роботи, це зламало й встановлення з уже випущеного носія 0.9.3, а не лише з новостворених.

Заміни, на яку можна було б перейти, не було. Розробники bubblewrap вилучили підтримку setuid у версії 0.12.0 через день після того, як 0.11.2 виправив CVE-2026-41163 — підвищення привілеїв, яке існувало лише в цьому режимі, — а гілку 0.11.x, яку зробили доступною для всіх, кому вона ще була потрібна, так ніхто й не перейняв.

Тож тепер схему обернено. Замість того щоб вимикати простори назв користувача для всіх і робити виняток для одного двійкового файлу, Ditana дозволяє їх для кожного виконуваного файлу окремо. Програма BPF, приєднана до хука ядра userns_create, відмовляє в просторі назв усьому, що не було оголошено, а оголошення міститься в конфігурації поруч із пакунком, якому потрібен простір назв:

- name="flatpak" default-value=#true {
    arch-packages "flatpak"
    userns-allow "/usr/bin/bwrap"
  }

Важливий момент, бо саме він визначає наслідки в разі помилок: хук такого типу може лише відмовляти, але ніколи не дозволяти. Значення sysctl, яке раніше вимикало простори назв користувача, потрібно підвищити, щоб захисному механізму було на що діяти, і підвищує його лише служба, яка вже завантажила й приєднала програму. Машина, яка не може завантажити програму, залишає простори назв користувача повністю вимкненими. У разі збою ви втрачаєте пісочниці, але ніколи — захист.

Захисний механізм — це окремий пакунок, ditana-userns-guard, який встановлюється разом із параметром System Hardening, що раніше називався «Disable unprivileged user namespaces».

LibreWolf тепер надходить з Arch

LibreWolf тепер надходить зі сховищ Arch, а не з Flathub, відповідно до ієрархії переваг, у якій нативний пакунок стоїть на першому місці. Brave і далі доступний через AUR; обґрунтування докладно викладено на сторінці AUR чи Flatpak.

Кожне значення sysctl оголошено як дані

Кожне значення sysctl, яке записує інсталятор, тепер оголошено як дані, а не складено як текст оболонки. Два налаштування, що записують той самий ключ із різними значеннями, зупиняють встановлення, причому названо обидва. Раніше записувалися обидва рядки, і мовчки перемагав останній.

Автоматичне встановлення

Тепер встановлення може відбуватися без жодної людини за клавіатурою. Файл відповідей заздалегідь надає те, що інсталятор зазвичай запитує, і міститься на невеликому конфігураційному диску, який інсталятор знаходить самостійно, — саме таку схему використав би хостинг-провайдер, щоб розгорнути Ditana через PXE. Жодні натискання клавіш ніде не імітуються: механізм полягає в тому, що інсталятор зчитує свої відповіді, а не запитує їх, і саме тому він працює для провайдера, а не лише для тесту.

Пароль облікового запису береться з файлу відповідей як хеш, ніколи — відкритим текстом. Приклад файлу є в сховищі інсталятора, і там же механізм повністю задокументовано.

Відповідь, яка не може набути чинності, зупиняє встановлення, а не відкидається мовчки: налаштування, якого ця машина не пропонує, і налаштування, яке типовий вираз знову перезаписав би, відхиляються із зазначенням назви, разом з умовою, яка робить їх неможливими. А оскільки на екран ніхто не дивиться, встановлення, яке зупинилося, записує причину в перший послідовний порт, і кожен рядок містить позначку DITANA-AUTOINSTALL-ABORT:, щоб система розгортання, яка читає консоль, дізнавалася причину, поки машина ще працює, а не вичікувала в тиші. Якщо консоль розташована деінде, її вказують у командному рядку ядра.

Те саме Ditana застосовує й до себе. Щоночі сервер збирання встановлює щойно зібране сховище у віртуальну машину без участі людини, і пакунки випускаються, лише якщо встановлена система завантажується й самостійно відповідає.

Див. docs/unattended-installation.md.

ZFS на інсталяційному носії

Live-носій завантажував ядро без модуля ZFS, через що встановлення з ZFS не вдавалося на обладнанні, на якому раніше воно проходило успішно. Тепер пакунки ZFS постачаються через pacstrap, після чого initramfs збирається заново, а zfsbootmenu додається хуком, який за нього відповідає, а не через другий шлях, що міг би з ним конфліктувати. Резервний шлях завантаження UEFI був неправильним, і його виправлено.

Друк

Підтримку принтерів завершено. У firewalld відкрито mDNS і ввімкнено avahi-daemon, тож мережевий принтер виявляється, а не вводиться вручну.

Обладнання

Мікропрограма деяких машин після призупинення залишає процесор у найменш глибокому стані простою, що витрачає енергію весь час, поки машина працює. Тепер Ditana виявляє це й застосовує обхідне рішення.

Новий параметр прив’язує відповіді ARP до інтерфейсу, який отримав запит. На машині з більш ніж одним інтерфейсом в одній підмережі ядро інакше відповідає з будь-якого інтерфейсу на власний розсуд, що плутає комутатори й деякі конфігурації балансування навантаження.

Виявлення графіки тепер з’ясовує не те, чи прискорює GPU хоч щось, а те, чи працює він під Wayland, — саме від цього насправді залежить вибір стільничного середовища.

Пам’ять

Параметр Extended ZRAM Overcommit збільшує віртуальний розмір стисненої резервної пам’яті (swap) в ОЗП зі 100% до 175% фізичної оперативної пам’яті, а рівень стиснення zstd — з 3 до 6, тож машина вміщує у стисненому вигляді приблизно в 1,75 раза більше, ніж обсяг її ОЗП, перш ніж звернутися до розділу резервної пам’яті на диску. Затримка під час зчитування сторінок назад у пам’ять (page-in) залишається такою самою, бо zstd розпаковує з однаковою швидкістю, хоч би яким дорогим був рівень стиснення. Типове значення залишається незмінним.

Сам інсталяційний носій

ISO-образ збирається за допомогою archiso 90. З нього вилучено b43-firmware: цей пакунок підтягував на носій основне ядро (mainline) поруч із тим, яке завантажує Ditana. Процес збирання став суворішим — ніщо, скопійоване на носій, тепер не може перейти за символьним посиланням назад у live-систему, права доступу до всього, що розміщується всередині, оголошуються, а не успадковуються, а кілька гігабайтів проміжних файлів зберігаються на диску, а не в tmpfs.

Носій містить стан, що перебуває під контролем версій, і нічого більше: файл, який лежить у робочому дереві й не оголошений жодним правилом сховища, зупиняє підписане збирання, бо все, що міститься під airootfs профілю, потрапляє в образ. Потім встановлена система записує своє походження як BUILD_ID і VERSION_CODENAME у /usr/lib/os-release: який носій її створив і який стан конфігурації цей носій містив.

Збирання, які можна перевірити

Кожен пакунок, який постачає Ditana, збирається заново зі свого оригінального рецепта, підписується й публікується лише як повний набір: якщо хоча б один пакунок не вдається зібрати або його джерела не вдається перевірити, не публікується взагалі нічого. Після 0.9.3 цей процес став видимим. Кожен прогін записується й оприлюднюється, зокрема й прогони, у яких нічого не опубліковано, а кожен перезібраний пакунок має посилання на журнал власного збирання.

Відтоді додано дві речі. Кожну зміну, яку вносить оригінальний рецепт, класифікують ще до того, як щось буде зібрано, і все, що не є безпечним за самою своєю будовою, зупиняє весь прогін, щоб на нього подивилася людина, — AUR став об’єктом активної атаки на ланцюг постачання, а Ditana перезбирає рецепти AUR у сховище, якому її користувачі довіряють через конфігурацію підписів pacman. І сховище, яке збирається й підписується без проблем, усе одно може виявитися таким, з якого ніхто не може встановити систему, тому перед випуском його встановлюють у віртуальну машину.

Конвеєр, на якому все це тримається, тепер теж публічний. Він старший за Ditana: він з’явився близько 2023 року як один сценарій оболонки й ніколи не призначався для чужих очей. Його опубліковано, тому що твердження сторінки стану збирання варті рівно стільки, скільки докази, на які вони спираються, а він є частиною цих доказів. Він розміщений на github.com/acrion/ditana-build, а записані ним прогони — на ditana.org/builds.

Пакунки підписуються окремим підключем підпису замість основного ключа. Відкликати й замінити підключ можна незалежно, і сертифікувати інші ключі він не може. Робити з цим нічого не потрібно: в’язку ключів, яка його містить, опубліковано в серпні, і її вже давно отримано.

Оновлення з 0.9.3

Системи, встановлені з носія 0.9.3, і далі працюють, за винятком одного випадку, який потрібно розв’язати вручну. bubblewrap-suid більше не існує, тож наступне оновлення системи замінює його, і Flatpak та Bubblejail перестають працювати на машині, де непривілейовані простори назв користувача вимкнено. Brave та інших застосунків з AUR це не стосується.

Рішення — описаний вище захисний механізм:

sudo pacman -Syu ditana-userns-guard
echo /usr/bin/bwrap | sudo tee /etc/ditana/userns-allow.conf
sudo systemctl enable --now ditana-userns-guard.service

Один абсолютний шлях на рядок; # починає коментар. Служба відмовляється підвищувати значення sysctl, якщо перед цим не завантажила й не приєднала програму, тож машина, на якій вона не може працювати, залишається заблокованою рівно так само, як і була.

Зі старішого носія встановити систему більше взагалі неможливо. Інсталятор отримує конфігурацію під час роботи, тож USB-накопичувач із 0.9.3 звертається по пакунки, яких його власне сховище вже не може надати, і зупиняється. Запишіть на нього поточний образ.

Для нового встановлення з носія 0.9.4 нічого з цього не потрібно.