Подписанный релиз, целый архив и повторяемая сборка — три разных доказательства

В релизном обсуждении легко услышать: «файл подписан, значит всё надёжно». Подпись действительно важна, но отвечает только на вопрос о происхождении и неизменности подписанной идентичности. Она не доказывает, что архив собран из ожидаемого коммита, что зависимости не изменились, что две сборки дадут одинаковые байты или что обновление заработает на конкретном сервере.

Спокойный выпуск строится как цепочка доказательств. У компонента есть версия и исходный коммит. У опубликованного артефакта — контрольная сумма. У релизной идентичности — подпись доверенным ключом. У сборки — зафиксированные входы. У развёртывания — журнал проверок, готовность, сквозной тест и критерий отката. Потеря любого звена оставляет отдельный вопрос без ответа.

Что подтверждает подпись

Для плагинов AiHummer модель доверия различает официальный источник, приватную загрузку и режим локальной разработки. Официальный пакет проверяется относительно закреплённого ключа реестра; приватный — относительно trust-store инстанса и одобренного оператором ключа автора. Неподписанный пакет допускается только в специально включённом режиме разработки, а не как обычный путь промышленной установки.

Обновление должно снова пройти проверку подписи. Нельзя считать новую версию доверенной только потому, что старая уже установлена. При этом подпись не проводит ревью кода и не обнаруживает логическую ошибку: она связывает данные с ключом. Поэтому хранение ключа, правила его ротации и процесс допуска автора остаются частью цепочки поставки.

Зачем нужен хеш

SHA-256 помогает заметить, что байты архива после публикации изменились. Хеш полезен при скачивании, переносе между хранилищами и повторной попытке после сетевого сбоя. Но одинаковый URL не гарантирует одинаковое содержимое, если объект по адресу можно заменить. Надёжнее связывать версию, точный URL, размер и хеш в неизменяемом манифесте.

Контрольная сумма тоже не говорит, хорош ли сам архив. Вредный или ошибочный файл может иметь идеально совпадающий хеш. Поэтому целостность проверяют вместе с происхождением, составом, тестами и политикой публикации. CLI AiHummer умеет упаковывать плагин в tarball с файлом .sha256, однако команда всё равно определяет, кто запускает упаковку и где сохраняется результат.

Что означает воспроизводимость

Воспроизводимая сборка требует закрепить исходный коммит, версии инструментов, зависимости, переменные и последовательность шагов. Плавающий пакет или динамический URL способен изменить результат при той же команде. Если полная побитовая воспроизводимость пока недостижима, полезно честно разделить уровни: повторяемая процедура, известный список компонентов и идентичные байты — не одно и то же.

Проверка на чистом хосте обнаруживает неявные зависимости: файл из домашнего каталога, кеш, глобально установленный пакет или ручной шаг. Сравните два результата по хешу и сохраните журнал среды. Расхождение не всегда означает атаку, но всегда требует объяснения до публикации.

Развёртывание — отдельный этап

Даже корректный артефакт может не запуститься из-за версии ОС, свободного места, миграции, базы или конфигурации. План обновления поэтому содержит предварительную проверку, резервную копию, проверку подписи и хеша, применение миграций, /readyz, сквозной тест по пользовательскому пути и наблюдение после запуска. Успех команды распаковки — лишь промежуточное событие.

Критерий отката формулируют до релиза. Какие симптомы требуют возврата? Совместима ли старая версия с уже применённой миграцией? Где лежит проверенная резервная копия? Кто принимает решение? «Откатимся, если что» не является планом, пока команда не прошла упражнение на отдельном контуре.

Манифест, который можно проверить

Включите в него компонент, версию, коммит, источник артефакта, размер, SHA-256, подпись, идентификатор ключа, закреплённые зависимости, список миграций, поддержанные платформы, результаты тестов и инструкцию отката. Каждое поле должно ссылаться на объект или лог, а не на устное подтверждение.

Перед выпуском попросите другого инженера пройти путь только по этому манифесту: скачать файл, проверить хеш и подпись, развернуть на чистой машине, подтвердить готовность, выполнить сквозной тест и вернуть систему назад. Все вопросы и ручные догадки становятся входом для следующего улучшения.

Ключ подписи — отдельный актив

Доверие к подписи зависит от того, кто контролирует приватный ключ. Ограничьте доступ к нему, отделите сборку от публикации и запишите процедуру ротации. Если ключ скомпрометирован, нужно уметь остановить выпуск, отозвать доверие и перевыпустить артефакт. Просто создать новый ключ недостаточно: потребители должны получить новый якорь по доверенному каналу.

Список материалов сборки помогает разбирать уязвимость зависимости. Даже если проект пока не выпускает формальный SBOM, сохраните версии прямых и транзитивных пакетов, базового образа или системных библиотек. При сообщении о проблеме команда быстро понимает, какие релизы затронуты. Плавающий диапазон версий делает такой ответ догадкой.

Проверяйте не только успешную установку, но и отказ. Измените один байт архива и убедитесь, что хеш или подпись отклоняет его. Подставьте неверный ключ, недоступный URL и несовместимую версию манифеста. Отрицательный тест показывает, что контроль действительно стоит на пути исполнения, а не существует только в инструкции.

После выката сохраните фактический набор доказательств: какой файл скачан, какой хеш получен, каким ключом проверен, кто одобрил, какие пробы прошли. Не включайте секреты в журнал. Такой протокол позволяет отличить повторное развёртывание того же релиза от похожей операции с изменившимся артефактом.

Приёмка перед публикацией

Соберите релиз из чистого окружения дважды и сравните результаты. Проверьте хеш скачанного файла, подпись и привязку к ожидаемой версии. Затем разверните пакет без доступа к кешу разработчика, выполните миграции, проверьте готовность и проведите сквозной тест. Наконец, намеренно испортите копию артефакта: проверка должна остановить установку до выполнения его кода. Сохраните результаты рядом с манифестом.

Отдельный рецензент должен подтвердить не только зелёный итог, но и соответствие версии, коммита и ключа. Автоматический CI полезен, однако правило «кто может опубликовать» и ручное решение о продвижении релиза остаются организационными. Никакая контрольная сумма не заменяет разделение полномочий.

Перед окончательным продвижением сравните опубликованное описание с самим архивом: версия, платформы, миграции и известные ограничения должны совпадать. Несоответствие документации — такой же повод остановиться, как неверный хеш.

Текущую пользовательскую историю версий смотрите в официальном журнале изменений, модель проверки пакетов — в установке и обновлениях, а команды упаковки и подписи — в Plugin SDK. Начните с манифеста одного компонента и проверьте, какие доказательства уже есть, а какие ещё предстоит получить.

Раз в цикл сопоставляйте правило с реальным маршрутом релиза: кто собирает пакет, кто сверяет источник и кто допускает его в рабочую среду. Если один человек незаметно выполняет все роли, зафиксируйте риск и добавьте независимую проверку до следующего продвижения.