Предположим, настольное приложение доступно на странице выпуска и зеркале. Имена файлов и версии совпадают, но остаются вопросы: одинаковы ли файлы, кто их выпустил, получены ли они из ожидаемого кода и процесса сборки и подходят ли для этого устройства?
Для этих вопросов нужны разные доказательства. Общее название «сертификат безопасности» создаёт ожидания, которых проверки не обеспечивают, и скрывает пробелы процесса выпуска от разработчиков.
Контрольная сумма проверяет совпадение файлов
Хеш скачанного файла, сравненный с ожидаемым, позволяет проверить совпадение содержимого. Важное условие: ожидаемое значение получено по доверенному каналу. Совпадение файла и хеша с одной непроверенной страницы не доказывает личность издателя.
Разные хеши означают различие файлов, но сами по себе не доказывают злой умысел. Причиной могут быть другая сборка, переупаковка или ошибочная загрузка. Перестаньте считать файл проверенным выпуском и уточните источник, платформу и соответствующую контрольную сумму.
Издателю следует совместно поддерживать понятные имена, версии и перечень хешей. Пользователь не должен копировать хеш старой статьи и сравнивать его с установщиком другой платформы или сборки.
Подпись требует проверки ожидаемой личности
Цифровая подпись связывает подписанта с данными, но нужно также установить, соответствует ли его личность ожидаемой. Документация Sigstore требует проверки подписи вместе с условиями идентичности и издателя удостоверения. Проверка Sigstore
При сообщении «подпись действительна» выясните, какого издателя или процесс она представляет. Разработчики должны указать, кому разрешено подписывать официальные выпуски. Любая математически корректная подпись не делает файл официальным.
При смене сертификатов или способа подписи издатель должен предоставить проверяемое объяснение. Просьба немедленно довериться неизвестному сертификату — не полноценная процедура обновления.
Происхождение связывает пакет с процессом сборки
Аттестации артефактов GitHub фиксируют происхождение сборки и помогают проверить связь результата с репозиторием и рабочим процессом. Они объясняют создание файла, но всё равно необходимо проверить сам артефакт и ожидаемую идентичность. Аттестации GitHub
Уровни сборки SLSA различают наличие сведений о происхождении, подписанные сведения от хостинговой платформы и более строгую защиту платформы сборки. Указывая уровень, объясняйте охват и основания: число не оценивает все риски ПО. Уровни SLSA
| Доказательство | Что помогает установить | Чего само по себе не доказывает |
|---|---|---|
| Контрольная сумма | Получено ли ожидаемое содержимое | Личность издателя и безопасность поведения |
| Цифровая подпись | Кто подписал какие данные | Соответствие подписанта вашим требованиям доверия |
| Происхождение сборки | Какой процесс создал артефакт | Отсутствие проблем в коде и зависимостях |
| Воспроизводимая сборка | Получается ли тот же артефакт в заданных условиях | Отсутствие уязвимостей и нежелательного поведения |
Эти доказательства дополняют друг друга. Объясняйте, какие предоставлены и какие проверки ещё следует выполнить независимо.
Воспроизводимость требует точных входных данных и среды
Проект Reproducible Builds определяет воспроизводимую сборку как получение побитно идентичных заданных артефактов из одинакового кода, среды и инструкций. Это точнее, чем «компилируется на моём компьютере». Определение воспроизводимости
Рекомендуем сохранять инструменты, фиксацию зависимостей, параметры сборки и их соответствие артефактам. Если воспроизводимость не достигнута, точно укажите, до какого этапа удалось пересобрать, не скрывая различия ради объявления успеха.
Нужно объяснять и содержимое публичного репозитория. Он может содержать основной код, а может — преимущественно инструменты, настройки и пакеты приложения, созданные выше по цепочке. Для оценки происхождения пользователю важно знать, что он реально способен изучить и пересобрать.
Практический порядок проверки загрузки
- Подтвердите репозиторий выпусков через официальный вход проекта, не полагаясь лишь на рекламу поиска или пересланные ссылки.
- Прочитайте описание выпуска и проверьте ОС, архитектуру процессора и канал.
- Сверьте файл с его хешем; при наличии подписи или происхождения проверьте ожидаемую идентичность и охват.
- Проверьте состояние сопровождения и ограничения: метка «последний» не означает готовности к промышленному применению.
- При противоречиях сохраните версию и имя файла и обратитесь за уточнением в поддержку проекта.
Это не требует от всех стать инженерами сборки. Продукт может организовать доказательства на понятной странице: происхождение файлов, подходящие пользователи, способы проверки и обращения при расхождениях.
Долговременное поддержание этой цепочки информации ценнее одноразового значка «проверено». При отзыве старой версии, смене подписи и сбое обновления объяснения должны оставаться доступными.
Описание публичного репозитория AlphaBiz различает инструменты сборки и пакеты приложения, созданные выше по цепочке. Для таких приложений следует точно описывать область проверки, не смешивая публичный репозиторий, полный исходный код и воспроизводимые выпуски. Описание AlphaBiz
Разработчик может начать с перечня доказательств выпуска, пользователь — с проверки одного файла часто используемого приложения. Расскажите в AlphaBiz Discussions, какие сведения о проверке вы хотели бы видеть на страницах выпусков.