Hacker News Digest

Автор обнаружил удивительное поведение shebang (#!) в Unix-системах: ядро Linux, FreeBSD и OpenBSD поддерживает не только абсолютные, но и относительные пути в shebang. Например, можно использовать "#!python3", "#!bin/python3" или "#!../../../usr/bin/python3", и они будут работать при правильном расположении текущего каталога. Это поведение существует с 4.2 BSD (1983 год) и реализовано через вызов namei(), который разрешает пути так же, как и для обычных файлов.

Несмотря на потенциальные проблемы безопасности, такое поведение сохранилось во многих системах. Автор предполагает, что это связано с простотой реализации в ядре и законом Хайрума (Hyrum's Law) - вероятно, кто-то уже использует эту функциональность и зависит от неё. Интересно, что даже OpenBSD, известный вниманием к безопасности, не изменил это поведение.

• Проблема с #!/bin/bash в NixOS и других системах, где bash не в /bin, подчеркивает важность использования #!/usr/bin/env bash для переносимости.
• Обсуждение подчеркивает, что #!/usr/bin/env bash является наиболее переносимой формой, так как она использует $PATH для поиска bash.
• Несколько участников подчеркивают, что #!/bin/bash может не работать в некоторых системах, где bash не в /bin.
• Обсуждение также затрагивает безопасность: #!/usr/bin/env bash может быть опасен, если не указан полный путь, так как это может привести к запуску нежелательного кода.

Автор делится положительным опытом использования Linux на ноутбуке Fujitsu Lifebook U729, отмечая, что система работает безупречно, а всё оборудование работает "из коробки". Основная сложность заключалась в отключении Secure Boot. После поломки экрана MacBook Air автор решил перейти на стационарную конфигурацию, но осознал необходимость портативного устройства. Вернувшись к Linux, особенно NixOS, он выбрал этот ноутбук благодаря отличному соотношению цена/характеристики: 16 ГБ оперативной памяти, 512 ГБ SSD за 250 австралийских долларов, компактным размерам и весу 1,1 кг.

Для отключения Secure Boot потребовался нетривиальный процесс: сначала установка Windows 11 с обновлением драйверов Fujitsu через Windows Update, затем обновление BIOS утилитой DeskUpdate. Только после обновления BIOS с версии 2.17 до 2.31 появилась возможность отключить Secure Boot и установить NixOS. Ноутбук также поставлялся с корпоративным шпионским ПО Absolute Persistence для защиты от краж. Автор подчеркивает, что несмотря на первоначальные сложности с Secure Boot, в целом опыт использования Linux на этом устройстве оказался исключительно положительным.

• Б/у корпоративные ноутбуки (ThinkPad, Dell) оптимальны для Linux: хорошее соотношение цены и качества, ремонтопригодность, совместимость.
• Критерии выбора: проверка заблокированного BIOS, репутация производителя по ремонту, избегание Intel из-за проблем с перегревом и батареей.
• Рекомендуемые модели: Lenovo Yoga Slim 7, Asus ProArt px13, старые MacBook Air, ARM-ноутбуки (Lenovo Chromebook Plus 14).
• Проблемы Windows 11: обязательная учётка Microsoft, сложный обход Secure Boot; критика Fujitsu из-за скандала с почтовыми отделениями.
• Переход с macOS: "тысячи порезов" в Linux, но ценится кастомизация; важны обновление BIOS перед установкой и проверка совместимости железа.

Автор столкнулся с загадкой в 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 остаётся интересным музейным экспонатом и источником идей, но не готов к «повседневному» использованию.