Bug 42693

(Ответ для mike.dev на комментарий #0)
> В отличие от образов дистрибутивов, файлы контрольных сумм образов
> StarterKit не снабжаются файлами цифровых подписей.
...и собираются по крону, хоть и с подготовкой к выпуску.

> Это делает невозможным верификацию скачанного образа с помощью открытого
> ключа сборочного сервера/мейнтейнера сборки. Для пользователя это создает
> риски, связанные с вредоносной модификацией скачиваемого образа через атаку
> на цепочку поставок (при скачивании с зеркала) или атаку человек-посередине
> (при скачивании по незащищенному каналу).
Прямщас практически достаточно сверки контрольных сумм полученных образов с файлами, взятыми с rsync://rsync.altlinux.org (или пересинхронизации образов именно с этим ресурсом).

Ваши соображения вполне понятны и логичны -- другой вопрос, что как проверкой подписей, так и пересинхронизацией озадачатся единицы, а выпускающий регулярки
и стартеркиты у нас и вовсе один на весь комплект (я много лет их делал и знаю,
каково это).

Думаю, среднесрочный вариант -- при подготовке образов к публикации на стадии, когда уже сформирован и набор образов, и контрольные суммы, забирать файлики
с суммами на какой-либо доверенный хост и там производить формирование подписей отдельным ключом, после чего выкладывать и файлы подписей файлов сумм.

Как это всё автоматизировать без очевидных дверных проёмов -- мне сходу неясно.
Потому в практическом плане и предлагаю rsync, как официально задокументировано для докачки на http://altlinux.org/Starterkits/Download

(In reply to Michael Shigorin from comment #1)
> (Ответ для mike.dev на комментарий #0)
> Прямщас практически достаточно сверки контрольных сумм полученных образов с
> файлами, взятыми с rsync://rsync.altlinux.org (или пересинхронизации образов
> именно с этим ресурсом).
Проблема с rsync в том, что он плейнтекстовый, поэтому он решает проблему только "битого" образа, но не злонамеренно модифицированного в результате указанных выше атак.

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

Гипотетически, если решать именно проблему доставки от сборочного сервера до пользователя и именно среднесрочно, подписывать возможно и на самом сборочном сервере:

$ cat "$GPG_PIN" | gpg --sign --detach-sig --batch --homedir "$GPG_HOME" --passphrase-fd 0 --pinentry-mode loopback --default-key "$GPG_KEY" --armor --output SHA256SUMS.gpg SHA256SUMS

Вместо cat "$GPG_PIN" может быть условный kwallet-query (или аналогичный тул), который будет анлочиться вручную после ребута сборочного сервера (это должно снизить риски открытого хранения ключа или его пина). В простейшем случае, ключ может вообще быть не защищен пином, на рассматриваемые в тикете риски это не повлияет.

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

$ cat SHA256SUMS | ssh "$SIGN_SRV" gpg --sign --detach-sig --batch --homedir "$GPG_HOME" --pinentry-mode cancel --default-key "$GPG_KEY" --armor > SHA256SUMS.gpg

В примере предполагается, что ключ не защищен пином, т.к. сам сервер достаточно надежно защищен (в том числе с помощью LUKS), хотя и здесь можно применить трюк с --passphrase-fd и условным kwallet-query. Чтобы со сборочного сервера нельзя было выполнить экспорт ключей, эту команду можно обернуть в execve внутри бинарника, на который повесить SUID-бит и входить по SSH от другого пользователя, который не имеет непосредственного доступа к ключам.

Благодарю за обратную связь!