HTTPS i una VPN no autentiquen el paquet que instal·leu

Una actualització falla, i el suggeriment del fil segueix una línia coneguda: el trànsit passa per una VPN, així que la baixada ha de ser fiable, i la comprovació de signatura s’afluixa per saltar l’error. Dues idees separades s’han fusionat en una frase. El xifrat protegeix un camí entre extrems; l’autenticació decideix si els bytes provenen de l’editor que volíeu. Un túnel aporta la primera i no diu res de la segona.

El símptoma sol ser un error de verificació en un amfitrió, en un dipòsit, mentre la resta s’actualitza amb normalitat. Aquesta forma ja diu que el camí de xarxa funciona i que el desacord és sobre la confiança.

Dos controls que responen preguntes diferents

La seguretat del transport respon qui hi ha a l’altre extrem d’aquesta connexió i si algú al camí la pot llegir o modificar. L’autenticació del paquet respon si aquest artefacte l’ha publicat l’autoritat que heu configurat, i ha de sobreviure a una baixada a través d’un mirall que no controleu.

Aquestes preguntes només se superposen a les vores. Un certificat correcte en un mirall demostra que el mirall és el mirall; no demostra que el mirall contingui contingut d’editor sense modificar. Un paquet signat demostra que l’editor el va signar; no us diu que la xarxa hagi lliurat la versió més nova ni que el dipòsit que heu indicat sigui el que la vostra organització va aprovar.

La manera de fallar que la gent crea desactivant comprovacions és una pèrdua permanent de la segona garantia, a canvi d’una baixada amb èxit. Aquest intercanvi és invisible fins al dia que importa.

Què autentica realment apt

El model d’APT és una cadena d’arxiu autenticada. Les metadades d’edició signades porten per suma de verificació als índexs de paquets, i aquests índexs porten per suma de verificació als fitxers individuals de paquet. Verificar la cadena és el que fa que un mirall sigui no fiable però utilitzable: el mirall pot servir el que vulgui, i la signatura de les metadades decideix si APT ho accepta.

Això deliberadament no és el mateix que comprovar la signatura del mantenidor en cada paquet instal·lat, i la distinció explica per què «el paquet està signat» i «l’arxiu està autenticat» s’usen indistintament en informes d’errors quan volen dir coses diferents.

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

Llegiu la sortida de l’actualització, no només el codi de sortida. APT anomena el dipòsit les metadades del qual han fallat, i aquest nom és la frontera a investigar. Un dipòsit marcat com a fiable sense verificació de signatura, o una anul·lació per a dipòsit insegur, és una decisió de configuració que algú va prendre i hauria de poder explicar.

La frescor és una propietat separada una altra vegada. Un fitxer de metadades signat vàlidament pot ser més antic que el que vau veure la setmana passada, i per això les metadades d’edició porten una caducitat i per això un problema de rellotge al client pot produir errors de verificació que semblen problemes de clau.

Què comprova dnf5 per separat

El costat RPM exposa dos commutadors diferents, i confondre’ls produeix la mateixa classe d’error en l’altra direcció. Un controla si els fitxers de paquet han de portar una signatura vàlida; l’altre controla si les metadades del dipòsit han d’estar signades. Es poden establir independentment, i un sistema pot ser estricte amb un i permissiu amb l’altre.

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

La consulta del paquet mostra com són les metadades de signatura de la còpia instal·lada, cosa que és una comprovació de realitat útil contra un fitxer de configuració que afirma rigor. El que no us diu és la política suportada de la distribució, i és la que hauríeu de seguir en lloc d’una instrucció genèrica «activeu GPG» d’un fòrum.

On els dos gestors difereixen, la diferència és arquitectònica i no un senyal que un sigui més feble. Tots dos autentiquen el contingut de l’editor; situen la signatura en punts diferents de la cadena.

Què afegeix el túnel i què no

Una VPN pot aportar una ruta necessària, mantenir el trànsit d’actualització fora d’una xarxa d’accés no fiable i reduir el que veu un observador local. Són beneficis operatius reals, i cap d’ells no és autenticació de l’editor.

HTTPS afegeix la seva pròpia garantia, i és més estreta del que sembla. Autentica l’extrem TLS al qual us heu connectat. Si aquest extrem és un mirall, heu autenticat el mirall, no el contingut de l’arxiu que serveix. Aquest és precisament el cas per al qual existeix la cadena de metadades signades.

Cap dels dos controls promet disponibilitat. Una xarxa pot negar el lliurament, i un objecte autenticat no és automàticament el més nou. Feu servir la política de frescor del gestor de paquets en lloc d’inferir-la de la presència d’una icona de cadenat.

Diagnostiqueu la frontera que ha fallat

Anomeneu l’etapa abans de canviar res: resolució DNS, el proxy o la ruta, la identitat de l’extrem TLS, l’autenticació de l’arxiu, les comprovacions de signatura del paquet o la instal·lació. Cadascuna té una forma d’error i un propietari diferents.

Reparar un camí de xarxa no hauria d’implicar mai declarar fiable una clau de signatura desconeguda, ignorar certificats o acceptar una configuració de dipòsit que no heu demanat. Si una clau ha rotat de debò, la distribució o el propietari del dipòsit publiquen la clau nova per un canal que podeu verificar, i aquesta és la correcció a aplicar.

Anoteu quina frontera ha fallat i qui en és el propietari. La propera fallada d’actualització serà en una altra frontera, i tenir la llista la converteix en un diagnòstic de cinc minuts en lloc d’una altra discussió sobre si el túnel fa segures les actualitzacions.