42693 2022-05-05 21:56:32 +0300 Отсутствуют цифровые подписи образов StarterKit 2022-05-06 15:48:45 +0300 1 1 3 Distributions Regular any не указана all Linux NEW P5 normal --- 33000 1 realjohndoe antohami mike sem cas oldest_to_newest 210413 0 realjohndoe 2022-05-05 21:56:32 +0300 В отличие от образов дистрибутивов, файлы контрольных сумм образов StarterKit не снабжаются файлами цифровых подписей. Это делает невозможным верификацию скачанного образа с помощью открытого ключа сборочного сервера/мейнтейнера сборки. Для пользователя это создает риски, связанные с вредоносной модификацией скачиваемого образа через атаку на цепочку поставок (при скачивании с зеркала) или атаку человек-посередине (при скачивании по незащищенному каналу). 210441 1 mike 2022-05-06 14:04:26 +0300 (Ответ для mike.dev на комментарий #0) > В отличие от образов дистрибутивов, файлы контрольных сумм образов > StarterKit не снабжаются файлами цифровых подписей. ...и собираются по крону, хоть и с подготовкой к выпуску. > Это делает невозможным верификацию скачанного образа с помощью открытого > ключа сборочного сервера/мейнтейнера сборки. Для пользователя это создает > риски, связанные с вредоносной модификацией скачиваемого образа через атаку > на цепочку поставок (при скачивании с зеркала) или атаку человек-посередине > (при скачивании по незащищенному каналу). Прямщас практически достаточно сверки контрольных сумм полученных образов с файлами, взятыми с rsync://rsync.altlinux.org (или пересинхронизации образов именно с этим ресурсом). Ваши соображения вполне понятны и логичны -- другой вопрос, что как проверкой подписей, так и пересинхронизацией озадачатся единицы, а выпускающий регулярки и стартеркиты у нас и вовсе один на весь комплект (я много лет их делал и знаю, каково это). Думаю, среднесрочный вариант -- при подготовке образов к публикации на стадии, когда уже сформирован и набор образов, и контрольные суммы, забирать файлики с суммами на какой-либо доверенный хост и там производить формирование подписей отдельным ключом, после чего выкладывать и файлы подписей файлов сумм. Как это всё автоматизировать без очевидных дверных проёмов -- мне сходу неясно. Потому в практическом плане и предлагаю rsync, как официально задокументировано для докачки на http://altlinux.org/Starterkits/Download 210460 2 realjohndoe 2022-05-06 15:48:45 +0300 (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 от другого пользователя, который не имеет непосредственного доступа к ключам. Благодарю за обратную связь!