HTTPS и VPN не аутентифицируют пакет, который вы устанавливаете

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

Симптом обычно — ошибка проверки на одном хосте, в одном репозитории, тогда как всё остальное обновляется нормально. Эта форма уже говорит, что сетевой путь работает, а разногласие касается доверия.

Два контроля, отвечающие на разные вопросы

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

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

Режим отказа, который люди создают, отключая проверки, — это безвозвратная потеря второй гарантии в обмен на одну успешную загрузку. Этот обмен невидим до дня, когда он становится важным.

Что на самом деле аутентифицирует apt

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

Это намеренно не то же самое, что проверка подписи сопровождающего на каждом установленном пакете, и это различие объясняет, почему в отчётах об ошибках «пакет подписан» и «архив аутентифицирован» употребляются как взаимозаменяемые, хотя означают разное.

apt-get update
apt-cache policy
apt-config dump | grep -iE 'AllowInsecure|AllowDowngrade'

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

Свежесть — снова отдельное свойство. Корректно подписанный файл метаданных может быть старше того, что вы видели на прошлой неделе, поэтому метаданные выпуска несут срок действия и поэтому проблема с часами на клиенте может давать ошибки проверки, похожие на проблемы с ключом.

Что dnf5 проверяет отдельно

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

dnf5 config-manager --dump 2>/dev/null | grep -iE 'gpgcheck|repo_gpgcheck'
rpm -q --qf '%{NAME} %{SIGPGP:pgpsig}\n' bash

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

Там, где два менеджера различаются, различие архитектурное, а не признак того, что один слабее. Оба аутентифицируют содержимое издателя; они размещают подпись в разных точках цепочки.

Что туннель добавляет, а что нет

VPN может обеспечить нужный маршрут, удержать трафик обновлений вне недоверенной сети доступа и уменьшить то, что видит локальный наблюдатель. Это реальные эксплуатационные преимущества, и ни одно из них не является аутентификацией издателя.

HTTPS добавляет собственную гарантию, и она уже, чем кажется. Он аутентифицирует конечную точку TLS, к которой вы подключились. Если эта конечная точка — зеркало, вы аутентифицировали зеркало, а не содержимое архива, которое оно отдаёт. Это именно тот случай, для которого существует цепочка подписанных метаданных.

Ни один из контролей не обещает доступность. Сеть может отказать в доставке, а аутентифицированный объект не обязательно самый новый. Используйте собственную политику свежести менеджера пакетов, а не выводите её из наличия значка замка.

Диагностируйте границу, которая не прошла

Назовите этап, прежде чем что-то менять: разрешение DNS, прокси или маршрут, идентичность конечной точки TLS, аутентификацию архива, проверки подписи пакета или установку. У каждого своя форма ошибки и свой владелец.

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

Запишите, какая граница не прошла и кто за неё отвечает. Следующий сбой обновления будет на другой границе, и наличие списка превращает его в пятиминутную диагностику вместо очередного спора о том, делает ли туннель обновления безопасными.