Mozilla отозвала и заменила субключ GPG, применявшийся для проверки подлинности релизных артефактов Firefox и Thunderbird. Причиной стало непреднамеренное размещение незашифрованной копии прежнего ключа в приватном репозитории GitHub. Об этом компания сообщила в официальном уведомлении.
Ротация затронула отдельные релизные файлы. Среди них тарболы для Linux, RPM-пакеты и файлы контрольных сумм. Доступ к репозиторию имела небольшая внутренняя группа. При этом все её участники уже обладали санкционированным доступом к ключу через другие каналы.
Как сообщается в заявлении Mozilla, анализ журналов аудита не выявил доказательств доступа посторонних лиц к раскрытому материалу. Тем не менее компания расценила произошедшее как угрозу безопасности цепочки поставок. В качестве меры предосторожности прежний ключ отозван. Для подписи новых релизов развёрнут свежий субключ.
Для большинства пользователей никаких действий не требуется. Исключение составляют администраторы. Они вручную проверяют GPG-подписи. Также это касается пользователей, устанавливающих Firefox из RPM-репозитория Mozilla. Им нужно обновить локальные ключевые материалы. Без этого система доверия не будет работать корректно.
Пользователи, получающие Firefox или Thunderbird через системные менеджеры пакетов, не затронуты. В этом случае подлинность пакетов проверяется ключами дистрибутива, а не Mozilla. Ротация касается только загрузок с сайта Mozilla и официального RPM-репозитория.
Mozilla опубликовала отпечатки новых ключей. Основной ключ имеет отпечаток 14F2 6682 D091 6CDD 81E3 7B6D 61B7 B526 D98F 0353. Субключ подписи - 827E 6586 0867 9618 CD34 9F93 678E 455D 7676 7AA3. Срок действия нового субключа - до 5 августа 2028 года. Пользователи Fedora 43 и новее получат обновлённый ключ автоматически. Он будет загружен во время ближайшего обновления пакетов. Совпадение отпечатка гарантирует принадлежность ключа Mozilla.
Роль GPG-подписей в распространении ПО сложно переоценить. Они подтверждают, что файл действительно выпущен разработчиком. Также проверяется отсутствие изменений по пути к пользователю. Подпись связывает артефакт с открытым ключом. Приватный ключ хранится у издателя. Поэтому раскрытие даже части ключевого материала вынуждает обновлять ключевую пару. Без этого невозможно отличить легитимные файлы от поддельных. В экосистеме Linux GPG-подписи используются повсеместно. Ими заверяются пакеты дистрибутивов, файлы образов, списки обновлений. Сбой в этой системе доверия приводит к отклонению легитимных обновлений. Также возможен приём поддельных.
Вместе с тем ручная замена потребуется на других дистрибутивах. К ним относятся Fedora 42 и более ранние версии, RHEL, Rocky Linux, AlmaLinux, а также системы на основе SUSE. Проблема в том, что DNF и Zypper не всегда заменяют отозванный ключ автоматически. Поэтому администраторам нужно выполнить команды в строгой последовательности.
Сначала удаляется старый ключ. Для этого используется команда
| 1 | sudo rpm -e --allmatches gpg-pubkey-14f26682d0916cdd81e37b6d61b7b526d98f0353 |
После этого импортируется новый:
| 1 | sudo rpm --import https://packages.mozilla.org/rpm/firefox/signing-key.gpg |
Затем на Fedora, RHEL, Rocky Linux и AlmaLinux очищается кэш DNF: sudo dnf clean all. Для openSUSE и SUSE выполняется sudo zypper refresh.
Mozilla предупреждает о типичной ошибке. Импорт нового ключа до удаления старого может завершиться успешно. Однако прежний ключ останется в базе доверия. В дальнейшем это приведёт к ошибкам проверки подписи при обновлении. По этой причине порядок действий менять нельзя.
Пользователям Thunderbird дополнительные действия с RPM не требуются. Mozilla не выпускает официальные RPM-пакеты для этой программы. Тем, кто проверяет подписи вручную, новые открытые ключи доступны в KEY-файлах Firefox Nightly. Также информацию об отзыве прежнего ключа можно получить через keys.openpgp.org. Перед импортом рекомендуется сверить отображаемый отпечаток с указанным в уведомлении. Это исключит подмену при передаче.
Для обычных пользователей Firefox и Thunderbird произошедшее не несёт прямой угрозы. Функциональность браузеров и почтового клиента не меняется. Обновления продолжают распространяться штатно. Основная нагрузка ложится на системных администраторов. Им приходится вручную обновлять ключевые материалы на серверах и в корпоративных окружениях. Это требует времени и внимательности. Ошибка в последовательности команд может привести к сбоям при будущих обновлениях.
Этот случай высвечивает проблему, выходящую за рамки отдельной компании. Приватные репозитории не являются безопасной границей для хранения незашифрованных приватных ключей. Даже при ограниченном доступе и отсутствии следов компрометации раскрытие ключа подрывает доверие к подлинности артефактов. В результате приходится проводить внеплановую ротацию. Вместе с ней приходит обновление ключевой инфраструктуры у множества пользователей.
Для организаций, использующих GPG-подписи в процессах поставки ПО, это стимул пересмотреть свои процедуры. Как показывает практика, случайное попадание ключевого материала в систему контроля версий происходит чаще, чем ожидается. Автоматическая проверка на наличие секретов в репозиториях и разделение сред разработки и выпуска могли бы предотвратить подобные последствия.
