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, удостоверяване на архива, проверки на подписа на пакета или инсталиране. Всеки има отделна форма на грешка и отделен собственик.

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

Запишете коя граница се е провалила и кой я притежава. Следващият отказ при обновяване ще е на друга граница и наличието на списъка го прави диагностика за пет минути вместо поредния спор дали тунелът прави обновяванията безопасни.