shluz-bin: публичный binary-only Nix flake

Этот репозиторий обновляет CI исходного forgejo-admin/shluz после build и clean-Debian smoke. Здесь нет Cargo/Rust сборки, исходников runtime или Actions. Поддерживается только x86_64-linux. Архив содержит статические shluzd, shluz, shluz-tui; Xray/ip/nft по-прежнему поставляет NixOS-модуль, не архив.

Что закреплено

metadata/release.json фиксирует полный SHA исходного standalone-репозитория, дату коммита, версию, target, URL и flat SHA256 архива. flake.lock копируется из того же исходного коммита. modules/shluz идентичен исходному модулю, кроме package.nix: stdenvNoCC проверяет/устанавливает prebuilt без патчинга ELF.

Каждому исходному SHA соответствует тег/release build-<полный-SHA>. Тег указывает на соответствующий commit binary flake, не на исходный SHA. Архив и SHA256SUMS хранятся как durable release assets (не git blobs и не временные Actions artifacts). Публикация: candidate commit в non-tag refs/shluz/staging/<полный source SHA> → draft с будущим build-тегом и target_commitish=candidate → upload → проверка обоих assets по прямым HTTPS /attachments/<проверенный-uuid> → publish создаёт Git-тег → проверка точного tag commit и опубликованного release → анонимное скачивание обычного planned release URL и проверка SHA256 → fetch тега → non-force fast-forward main. Во время draft build Git-тег отсутствует: Forgejo 16 tag sync иначе может сам опубликовать draft. Staging создаётся только атомарным create-only CAS с точным empty-expected --force-with-lease; для main/build-тегов force/lease запрещён. Staging refs сохраняются, не перезаписываются и не являются consumer branches/tags. Сбой оставляет прежний main; orphan staging/draft/чужой тег требует ручного разбора. Publisher не удаляет/не заменяет refs или assets и не возобновляет partial draft; recovery допускается только для полностью проверенного опубликованного build. Идентичный опубликованный build проверяется и может дать no-op; другой hash, чужое состояние, stale/divergent источник или конфликт ветки — ошибка, не откат. После конфликта main опубликованный build доступен по своему immutable тегу. Это политика CI, не серверный WORM: нужны защита тегов/main и ограничение write-доступа.

Подключение по публичному HTTPS

inputs.shluz = {
  url = "git+https://fjo.osds.digital/forgejo-admin/shluz-bin.git?ref=main";
  inputs.nixpkgs.follows = "nixpkgs";
};
# В nixosSystem.modules:
# shluz.nixosModules.default
# { programs.shluz.enable = true; users.users.my-user.extraGroups = [ "shluz" ]; }

Экспорты: packages.x86_64-linux.default/shluz, apps.x86_64-linux.default (CLI), shluz, shluzd, shluz-tui, nixosModules.default/shluz. Для точного pin используйте ?ref=build-<полный-SHA> и закоммитьте consumer lock.

Репозиторий и release assets доступны публично по https://fjo.osds.digital/forgejo-admin/shluz-bin. Для Git flake и архива не нужны PAT, netrc или вход в Forgejo. builtins.fetchurl проверяет фиксированный flat hash; TLS verification остаётся включённой. Publisher запрещает redirects и проверяет архив после publish без Authorization/credentials, до продвижения main. Если репозиторий неожиданно стал private или анонимная проверка не прошла, main не продвигается. Scoped write secret SHLUZ_BIN_TOKEN остаётся приватным секретом исходного CI, ограниченным только binary repo; потребителю он не нужен.

Старые commits/tags/releases/manifests не переписываются: прежние pins могут содержать старый HTTP URL. Для перехода на HTTPS обновите consumer lock до нового main или нового build-<полный-SHA>, созданного после миграции. Publisher признаёт только проверенный legacy checkpoint для локальной сверки истории; он не скачивает legacy URL и не отправляет туда токен. Новая сборка получает новый flake commit, immutable build tag и release с публичным HTTPS URL.

Обновление не означает активацию

CI автоматически публикует trusted push main/v* и manual-main. Потребитель остаётся на старом input lock, пока явно не выполнит обновление и rebuild:

nix flake update shluz
sudo nixos-rebuild switch --flake .#my-host

Сам push/новый release не меняет работающие хосты. Runtime/per-app проверки и VM gate остаются ответственностью исходного проекта/оператора; --help smoke не доказывает работу dataplane. Не включайте Actions в этом репозитории: publisher живёт только в исходном ci/, рекурсивная публикация не нужна.