HTTPS e unha VPN non autentican o paquete que instalas

Unha actualización falla, e a suxestión do fío segue unha liña coñecida: o tráfico cruza unha VPN, así que a descarga debe ser fiable, e a comprobación de sinatura relaxase para pasar do erro. Dúas ideas separadas fusionáronse nunha soa frase. O cifrado protexe un camiño entre extremos; a autenticación decide se os bytes viñeron do publicador que pretendías. Un túnel fornece a primeira e non di nada da segunda.

O síntoma adoita ser un erro de verificación nun só host, nun só repositorio, mentres todo o demais se actualiza con normalidade. Esa forma xa di que o camiño de rede funciona e que o desacordo é sobre a confianza.

Dous controis que responden preguntas distintas

A seguridade do transporte responde quen está no outro extremo desta conexión e se alguén no camiño pode lela ou modificarla. A autenticación do paquete responde se este artefacto o publicou a autoridade que configuraches, e ten que sobrevivir a unha descarga a través dun espello que non controlas.

Esas preguntas só se solapan nos bordos. Un certificado correcto nun espello demostra que o espello é o espello; non demostra que o espello conteña contido do publicador sen modificar. Un paquete asinado demostra que o publicador o asinou; non che di que a rede entregase a versión máis recente nin que o repositorio que sinalaches sexa o que aprobou a túa organización.

O modo de fallo que a xente crea ao desactivar comprobacións é unha perda permanente da segunda garantía, a cambio dunha descarga exitosa. Ese intercambio é invisible ata o día en que importa.

Que autentica realmente apt

O modelo de APT é unha cadea de arquivo autenticada. Os metadatos de publicación asinados levan mediante suma de comprobación aos índices de paquetes, e eses índices levan mediante suma de comprobación aos ficheiros individuais de paquete. Verificar a cadea é o que fai que un espello sexa non fiable pero utilizable: o espello pode servir o que queira, e a sinatura dos metadatos decide se APT o acepta.

Iso deliberadamente non é o mesmo que comprobar a sinatura dun mantedor en cada paquete instalado, e a distinción explica por que «o paquete está asinado» e «o arquivo está autenticado» se usan indistintamente nos informes de erros cando significan cousas distintas.

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

Le a saída da actualización, non só o código de saída. APT nomea o repositorio cuxos metadatos fallaron, e ese nome é a fronteira que hai que investigar. Un repositorio marcado como de confianza sen verificación de sinatura, ou unha anulación para un repositorio inseguro, é unha decisión de configuración que alguén tomou e debería poder explicar.

A frescura é outra vez unha propiedade aparte. Un ficheiro de metadatos asinado validamente pode ser máis antigo que o que viches a semana pasada, por iso os metadatos de publicación levan unha caducidade e por iso un problema de reloxo no cliente pode producir erros de verificación que parecen problemas de chave.

Que comproba dnf5 por separado

O lado RPM expón dous interruptores distintos, e confundilos produce a mesma clase de erro na dirección contraria. Un controla se os ficheiros de paquete deben levar unha sinatura válida; o outro controla se os metadatos do repositorio deben estar asinados. Pódense axustar de forma independente, e un sistema pode ser estrito cun e permisivo co outro.

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

A consulta do paquete mostra como son os metadatos de sinatura da copia instalada, o que é unha comprobación de realidade útil fronte a un ficheiro de configuración que afirma rigor. O que non che di é a política soportada da distribución, e é a que deberías seguir en lugar dunha instrución xenérica de «activa GPG» dun foro.

Onde os dous xestores difiren, a diferenza é arquitectónica e non un sinal de que un sexa máis feble. Ambos autentican o contido do publicador; sitúan a sinatura en puntos distintos da cadea.

Que engade o túnel e que non

Unha VPN pode fornecer unha ruta necesaria, manter o tráfico de actualizacións fóra dunha rede de acceso non confiable e reducir o que ve un observador local. Son beneficios operativos reais, e ningún deles é autenticación do publicador.

HTTPS engade a súa propia garantía, e é máis estreita do que parece. Autentica o extremo TLS ao que te conectaches. Se ese extremo é un espello, autenticaches o espello, non o contido do arquivo que serve. Este é precisamente o caso para o que existe a cadea de metadatos asinados.

Ningún dos dous controis promete dispoñibilidade. Unha rede pode negar a entrega, e un obxecto autenticado non é automaticamente o máis recente. Usa a política de frescura do propio xestor de paquetes en lugar de inferila da presenza dunha icona de cadeado.

Diagnostica a fronteira que fallou

Nomea a etapa antes de cambiar nada: resolución DNS, o proxy ou a ruta, a identidade do extremo TLS, a autenticación do arquivo, as comprobacións de sinatura do paquete ou a instalación. Cada unha ten unha forma de erro e un propietario distintos.

Reparar un camiño de rede nunca debería implicar declarar de confianza unha chave de sinatura descoñecida, ignorar certificados ou aceptar unha configuración de repositorio que non pediches. Se unha chave realmente rotou, a distribución ou o propietario do repositorio publican a chave nova por unha canle que podes verificar, e esa é a corrección que hai que aplicar.

Anota que fronteira fallou e quen é o seu dono. O próximo fallo de actualización estará noutra fronteira, e ter a lista convérteo nun diagnóstico de cinco minutos en lugar doutra discusión sobre se o túnel fai seguras as actualizacións.