Hacker News Digest

Автор столкнулся с загадкой в Nix: имея бинарник Ruby, он не мог найти соответствующий .drv файл, хотя база данных и кэш NixOS указывали на его существование. Команда nix-store --query выдавала ошибку, а файл отсутствовал в системе, хотя nix derivation show находил совершенно другой .drv файл для того же бинарника. Это противоречило его пониманию работы Nix.

Ключ к разгадке — "fixed-output derivations" (FOD). Автор демонстрирует, что изменения в FOD (даже добавление мусорных атрибутов) изменяют путь самого .drv файла, но не затрагивают выходной путь (/nix/store/...). Это свойство "modulo" означает, что выходные пути зависят только от содержимого, а не от метаданных. В результате для одного бинарника может существовать несколько .drv файлов с разными хэшами, что объясняет парадокс: кэш NixOS указывает на один .drv, а nix derivation show находит другой, но оба ведут к одному и тому же выходному пути.

• Проблема deriver в Nix — это давняя проблема, которая не решается, потому что она не может обеспечить трассируемость от вывода к исходному выражению, что и было первоначальной целью.
• Пользователи сталкиваются с путаницей, когда кэш бинарников не совпадает с локальной оценкой, что приводит к непониманию и неэффективному использованию кэша.
• Появление CA-derivations и фиксированных выводов (fixed-output derivations) усугубляет ситуацию, делая проблему более заметной, но не решает ее.
• Сообщество обсуждает, что необходимо переписать Nix с нуля, чтобы устранить такие архитектурные проблемы, включая проблему deriver.
• Некоторые участники обсуждения подчеркивают, что Guix может быть альтернативой, но его недостаток в количестве пакетов делает его менее привлекательным.

Опасная уязвимость в GitHub Actions позволила бы злоумышленникам выполнять произвольный код в CI/CD пайплайнах проектов с открытым исходным кодом, используя функцию pull_request_target.

Основная проблема заключалась в том, что некоторые рабочие процессы в nixpkgs использовали pull_request_target и доверяли коду из форков, выполняя команды вроде xargs над именами файлов из PR. Это позволило бы атакующему создать файл с именем вроде --help, который интерпретировался бы как флаг для утилиты, что привело бы к выполнению произвольного кода.

Более серьёзный случай включал симлинки: рабочий процесс проверки CODEOWNERS мог быть обманнут для чтения произвольных файлов с диска, включая файлы учётных данных. Если бы атакующий смог заставить систему прочитать файл с учётными данными, он мог бы украсть токены GitHub.

К счастью, эти уязвимости были обнаружены и исправлены до того, как их могли эксплуатировать. Авторы рекомендуют всем, кто использует pull_request_target, тщательно проверять свои рабочие процессы и избегать доверия к коду из форков.

• Проблема в том, что pull_request_target в GitHub Actions позволяет уязвимости, но при этом остаётся единственным способом запуска CI для форков в организациях, не использующих форки.
• Подверженность pull_request_target в действии: злоумышленник может украсть токены и секреты, используя триггер, что приводит к тому, что вредоносный код может быть запущен в контексте базовой ветви.
• Предложение: GitHub должен либо полностью отключить pull_request_target, либо предоставить безопасный способ запуска CI для форков.
• Параллельно обсуждается, что если бы NixOS принял предложение обеспечивать подпись коммитов и независимые воспроизводимые сборки, как это делает Guix, то подобные атаки были бы невозможны.

Пакет tinycc, cdimgtools, docutils и ещё несколько пакетов, использующих fetchFromRepoOrCz, не могут скачать исходники из-за блокировки GitHub в Великобритании. Это приводит к сбою сборки NixOS/nixpkgs. Проблема в том, что fetchFromGitHub внутри fetchFromRepoOrCz не использует зеркало, а GitHub блокирует IP-адреса из Великобритании. Предлагается добавить зеркало GitHub в fetchFromGitHub и использовать его по умолчанию.

• repo.or.cz блокируется в Великобритании из-за OSA 2023; сайт объясняет, что не может выполнять «риск-оценку» и поэтому блокирует весь трафик из UK.
• Пользователи Nix, которые не используют кеш, сталкиваются с ошибкой «не могу скачать исходники», но большинство пользователей не замечают проблемы.
• Обсуждение вышло за рамки: обсуждается, что UK не должен блокировать научные и экономические данные, а также то, что Git-хостинги не могут нести ответственность за пользовательский контент.
• Участники обсуждают, что техническое решение — переход на content-addressed модель, как у Nix уже сейчас, — может быть единственным способом избежать подобных блокировок в будущем.

Omarchy — мой новый проект: готовая, «моя» версия Arch + Hyprland. Устанавливаешь — получаешь то, что я использую каждый день.

Hyprland красив, но «из коробки» пуст: нет даже экрана блокировки. Omarchy решает это: красивые конфиги и нужный софт уже на месте.

Это не замена Omakub (Ubuntu), а продвинутый путь для тех, кому Arch ближе.

Linux на десктопе? Valve, Steam Deck, креаторы вроде PewDiePie и проекты вроде Hyprland делают его всё более заманчивым.

• Вышел Omarchy 2.0 — готовый Arch-ISO с Hyprland, ставится за ~5 минут.
• Большинство обсуждают Hyprland: кто-то в восторге от тайлинга и «веселья» Linux, кто-то считает слишком «голым» и сложным.
• Часть пользователей предпочитает плавующие окна или другие WM; другие перешли с macOS на Fedora/Gnome.
• Упоминаются альтернативы: NixOS, Bluefin, Omakub, Zorin, Rectangle/AeroSpace на macOS.
• Некоторые критикуют Hyprland за конфликты в сообществе и «токсичность», но число пользователей растёт.

Debian GNU/Hurd 2025 — неофициальный релиз Debian, но официальный порт.
Основан на «sid» в момент выхода «Trixie».

• ISO: hurd-i386 | hurd-amd64
• Образы и инструкции: hurd-install

Архитектуры: i386, amd64; покрытие ~72 % архива Debian.

Новое

• 64-бит полностью готов, драйверы дисков через Rump (NetBSD).
• xattr по умолчанию для трансляторов; mmdebstrap из других ОС.
• Порт Rust, USB-диски и CD через Rump.
• SMP, xkb-раскладки, framebuffer, acpi, rtc, apic, hpet.
• Исправления irqs, nfsv3, libports, pipes и др.

Документация

• FAQ
• Translator primer

Присоединяйтесь: contributing

• Hurd — давний проект с микроядром Mach, фактически движимый одним человеком (Samuel Thibault), и сегодня выглядит скорее хобби-экспериментом, чем реальной альтернативой Linux.
• Участники обсуждают низкую поддержку железа, архаичную архитектуру и отсутствие прогресса: «ждать совершенства — значит никогда не стать готовым».
• Предлагаются новые микроядра (seL4, L4, Viengoos) и языки (Rust, Zig), но критика считает это погоней за хайпом.
• GUIX/Nix и GNU Shepherd упоминаются как более живые GNU-ориентированные проекты; GUIX уже умеет запускать Hurd в виртуалке.
• Итог: Hurd остаётся интересным музейным экспонатом и источником идей, но не готов к «повседневному» использованию.