Отозван ключ подписи пакета: что делать и как восстановить работу репозитория

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

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

Зачем нужен ключ подписи пакета

Менеджер пакетов (apt, dnf/yum, zypper, pacman) перед установкой проверяет цифровую подпись каждого пакета или метаданных репозитория. Подпись создаётся закрытым ключом разработчика, а проверка выполняется по открытому ключу, который хранится в локальном хранилище доверия вашей системы. Если подпись совпадает с ожидаемой, система делает два вывода:

• Подлинность. Пакет действительно выпущен владельцем ключа, а не подделан третьей стороной.
• Целостность. Содержимое пакета не изменилось после подписания — ни при передаче, ни на зеркале.

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

Почему ключи вообще отзываются

Причин несколько, и от причины зависит порядок действий.

• Плановая ротация. Ключи имеют срок действия. Организация заранее выпускает новый ключ, публикует его в официальных источниках и постепенно переводит репозитории на новую подпись. Старый ключ истекает или отзывается.
• Компрометация. Есть основания считать, что закрытый ключ утёк или был украден. Отзыв объявляется экстренно, часто вместе с рекомендацией немедленно обновить пакеты из доверенного источника.
• Смена инфраструктуры. Компания меняет систему сборки, юридическое лицо или домен и переходит на новые ключи.
• Локальная проблема. Ключ на самом деле не отозван: повреждено локальное хранилище, устарели метаданные, сбились часы системы (просроченные сертификаты часто выглядят как «отозванные»), либо вы подключены к неофициальному зеркалу со старыми данными.

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

Шаг 1. Прочитайте ошибку целиком

Типичные формулировки различаются, но смысл легко распознать:

• «The following signatures were invalid: KEYEXPIRED» — срок действия ключа истёк. Часто это просто забытая ротация у вендора или давно необновляемая система.
• «NO_PUBKEY» — нужного открытого ключа нет в локальном хранилище. Это не отзыв, а отсутствие ключа: репозиторий новый или ключ не импортирован.
• «REVKEYSIG», «key was revoked» — ключ явно помечен как отозванный. Требует осторожности: сначала убедитесь, что отзыв официальный.
• «Signature doesn’t match», «checksum mismatch» — подпись или контрольная сумма не совпали. Возможны повреждение загрузки, устаревшее зеркало или подмена данных.

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

Шаг 2. Найдите официальное объявление

Прежде чем что-либо менять в системе, выясните позицию того, кто подписывает пакеты:

1. Проверьте сайт вендора или проекта, новостной раздел, блог и список рассылки (announce-рассылки дистрибутивов). Отзыв ключа — всегда публичное событие, особенно если речь о компрометации.
2. Сверьте отпечаток ключа из сообщения об ошибке с отпечатком, опубликованным на официальном сайте. Совпадает — значит, речь о вашем ключе, и дальше действуйте по инструкции вендора.
3. Если объявления нет, а ошибка появилась внезапно, проверьте дату и время на вашей машине. Расхождение системных часов на годы — частая причина ложных ошибок валидности подписей.
4. Убедитесь, что используете официальное зеркало. Неофициальные зеркала могут отдавать устаревшие метаданные, подписанные уже отозванным ключом.

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

Шаг 3. Обновите ключи из доверенного канала

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

Debian, Ubuntu и производные (apt)

Ключи базовых репозиториев входят в пакет apt-инфраструктуры дистрибутива и обновляются вместе с системой. Поэтому первый шаг простой:

1. Обновите списки пакетов и саму систему пакетов командами обновления индексов и апгрейда. Часто после этого ошибка исчезает, потому что ставится свежий набор ключей.
2. Для сторонних репозиториев (PPA, репозитории вендоров ПО) ключ обычно поставляется отдельным пакетом или добавляется вручную. Ищите актуальную инструкцию подключения на официальном сайте вендора: она содержит и адрес репозитория, и способ импорта нового ключа.
3. После импорта сверьте отпечаток добавленного ключа с опубликованным на сайте вендора. Команды просмотра ключей хранилища есть в документации apt/gpg.
4. Удалите отозванный ключ из хранилища, если инструкция это предусматривает, чтобы он не мешал диагностике в будущем.

RHEL, CentOS, Fedora и производные (dnf/yum)

Здесь ключи привязаны к описанию репозитория через параметр gpgkey и файлы в каталоге ключей системы:

1. Обновите систему: ключи дистрибутива приходят с обновлением соответствующих пакетов.
2. Для стороннего репозитория переустановите его конфигурационный пакет (обычно называется вида «release» или «repo») — он несёт актуальный ключ и описание репозитория.
3. Если ключ импортируется вручную, используйте файл ключа, загруженный с официального сайта по HTTPS, и проверьте его отпечаток до импорта.

Другие менеджеры пакетов

В openSUSE (zypper), Arch Linux (pacman) и других системах логика та же: обновить связку ключей средствами самого дистрибутива (в Arch, например, существует отдельный инструмент для синхронизации и обновления связки ключей), затем переимпортировать ключи сторонних репозиториев из официальных источников. Уточняйте команды в документации конкретной версии — они периодически меняются.

Чего делать нельзя

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

• Отключать проверку подписей (флаги вроде —no-gpg-checks, —allow-unauthenticated, снятие gpgcheck). Даже временно это превращает установку любого пакета из этого репозитория в лотерею.
• Импортировать ключ по ссылке из письма, чата или форума без сверки отпечатка с официальным сайтом вендора. Подмена ключа — классический способ внедрить вредоносный пакет.
• Игнорировать ошибку и продолжать обновляться в надежде, что «само пройдёт». Часть пакетов перестанет ставиться, часть — поставится со старой подписью, и вы потеряете контроль над состоянием системы.
• Удалять все ключи подряд, пытаясь «почистить хранилище». Можно сломать доверие к базовым репозиториям и получить систему, которая не сможет установить даже исправление безопасности.

Как проверить, что всё сделано правильно

После обновления ключей выполните короткую проверку:

1. Обновите индексы/метаданные репозиториев и убедитесь, что предупреждения о подписях исчезли.
2. Выполните пробную установку или симуляцию обновления (в большинстве менеджеров есть режим «только показать, что будет сделано») и посмотрите, что проверка подписей проходит без замечаний.
3. Просмотрите список доверенных ключей и найдите там новый ключ с корректным отпечатком и сроком действия; старый отозванный ключ должен отсутствовать или быть помечен как отозванный.
4. Проверьте, что системные часы синхронизированы — это убережёт от повторных ложных срабатываний.

Особый случай: компрометация ключа

Если вендор объявил, что ключ не просто сменился, а был скомпрометирован, порядок действий строже:

1. Прочитайте официальное объявление полностью: там обычно указано, какие версии пакетов затронуты и какие действия рекомендованы.
2. Обновите все пакеты, подписанные скомпрометированным ключом, из доверенного репозитория — новые версии будут подписаны новым ключом.
3. Импортируйте новый ключ только после сверки отпечатка.
4. Если вендор рекомендует дополнительные проверки целостности (сверку контрольных сумм отдельных файлов, повторную верификацию системы), выполните их, прежде чем считать проблему закрытой.
5. Для критичной инфраструктуры рассмотрите аудит: какие пакеты были установлены за период возможной компрометации и из каких источников.

Самостоятельно оценивать «насколько вероятно, что мне достался вредоносный пакет» не стоит — следуйте инструкциям вендора, у него больше информации о масштабе инцидента.

Типичные ошибки и как их избежать

Ошибка	Последствие	Правильное действие
Отключить проверку подписи, чтобы поставить пакет прямо сейчас	Система принимает любые пакеты из этого источника, включая подменённые	Обновить ключи из официального канала; при невозможности — дождаться исправления вендора
Скачать ключ по ссылке из уведомления об ошибке	Возможна подмена ключа и внедрение вредоносного ПО	Взять ключ с официального сайта и сверить отпечаток посимвольно
Продолжать пользоваться неофициальным зеркалом	Устаревшие метаданные, повторяющиеся ошибки подписей	Переключиться на официальное зеркало или зеркало, рекомендованное вендором
Не заметить расхождение системных часов	Ложные ошибки «ключ просрочен/отозван»	Настроить синхронизацию времени и повторить обновление
Удалить ключ, не убедившись, что новый уже работает	Разрыв доверия ко всем пакетам источника	Сначала импортировать и проверить новый ключ, затем удалять старый

Сценарии: что делать в зависимости от ситуации

• Ошибка KEYEXPIRED на давно необновляемом сервере. Скорее всего, ключи дистрибутива просто устарели. Обновите связку ключей штатными средствами дистрибутива и повторите обновление. Если система настолько стара, что её репозитории переведены в архив, потребуется подключить архивный источник по инструкции дистрибутива.
• Ошибка появилась сразу после добавления нового стороннего репозитория. Вы пропустили импорт ключа или импортировали не тот. Вернитесь к официальной инструкции подключения репозитория и выполните её заново.
• Ошибка на всех машинах организации одновременно. Почти наверняка вендор провёл ротацию ключа. Проверьте объявления, подготовьте единый порядок обновления ключей и примените его централизованно, а не вручную на каждой машине.
• Ошибка только на одном узле. Сравните его состояние с рабочими машинами: версия менеджера пакетов, содержимое хранилища ключей, настройки времени, используемые зеркала. Локальная причина почти всегда находится этим сравнением.
• Вендор объявил компрометацию. Действуйте по разделу выше: обновление из доверенного источника, новый ключ после сверки отпечатка, дополнительные проверки по рекомендации вендора.

Как снизить риск в будущем

• Регулярно обновляйте системы: большинство проблем с ключами решается ещё до того, как вы их заметите, потому что новые ключи приходят с обновлениями.
• Храните отпечатки ключей важных сторонних репозиториев в внутренней документации и сверяйте их при каждом изменении конфигурации.
• Подключайте сторонние репозитории только по HTTPS и только с официальных сайтов вендоров.
• Следите за announce-каналами дистрибутивов и критичного ПО: сообщения о ротации и отзыве ключей публикуются там заранее или незамедлительно.
• Настройте мониторинг времени (NTP) на серверах — банальная причина множества ложных тревог.

Главное

Отзыв ключа подписи — это сигнал проверить цепочку доверия, а не повод её обходить. Алгоритм короткий: прочитать ошибку и зафиксировать отпечаток ключа, найти официальное объявление вендора, обновить ключи из доверенного канала, сверить отпечатки, удалить старый ключ и убедиться, что обновления снова проходят с проверкой подписей. Если объявление говорит о компрометации — дополнительно обновите затронутые пакеты и выполните рекомендованные вендором проверки. Единственный недопустимый вариант — отключение проверки подписей: оно экономит минуты сейчас и создаёт риск на месяцы вперёд.

Материал носит информационный характер. Конкретные команды, имена пакетов и порядок действий зависят от дистрибутива, его версии и политики вендора — сверяйтесь с официальной документацией вашего дистрибутива и объявлениями вендора на дату обращения, а при работе с критичной инфраструктурой привлекайте ответственного администратора или специалиста по информационной безопасности.