HTTPS y una VPN no autentican el paquete que instalas

Una actualización falla, y la sugerencia del hilo sigue una línea conocida: el tráfico cruza una VPN, así que la descarga debe de ser fiable, y la comprobación de firma se relaja para pasar del error. Dos ideas distintas se han fusionado en una frase. El cifrado protege una ruta entre extremos; la autenticación decide si los bytes vinieron del publicador que pretendías. Un túnel aporta lo primero y no dice nada de lo segundo.

El síntoma suele ser un error de verificación en un host, en un repositorio, mientras todo lo demás se actualiza con normalidad. Esa forma ya dice que la ruta de red funciona y que el desacuerdo es sobre la confianza.

Dos controles que responden preguntas distintas

La seguridad del transporte responde quién está al otro lado de esta conexión y si alguien en la ruta puede leerla o modificarla. La autenticación del paquete responde si este artefacto lo publicó la autoridad que configuraste, y tiene que sobrevivir a una descarga a través de un espejo que no controlas.

Esas preguntas solo se solapan en los bordes. Un certificado correcto en un espejo demuestra que el espejo es el espejo; no demuestra que el espejo contenga contenido del publicador sin modificar. Un paquete firmado demuestra que el publicador lo firmó; no te dice que la red haya entregado la versión más reciente ni que el repositorio que señalaste sea el que aprobó tu organización.

El modo de fallo que la gente crea al desactivar comprobaciones es una pérdida permanente de la segunda garantía, a cambio de una descarga exitosa. Ese intercambio es invisible hasta el día en que importa.

Qué autentica realmente apt

El modelo de APT es una cadena de archivo autenticada. Los metadatos de publicación firmados llevan mediante suma de comprobación a los índices de paquetes, y esos índices llevan mediante suma de comprobación a los archivos individuales de paquete. Verificar la cadena es lo que hace que un espejo sea no fiable pero utilizable: el espejo puede servir lo que quiera, y la firma de los metadatos decide si APT lo acepta.

Eso deliberadamente no es lo mismo que comprobar la firma de un mantenedor en cada paquete instalado, y la distinción explica por qué «el paquete está firmado» y «el archivo está autenticado» se usan indistintamente en informes de errores cuando significan cosas distintas.

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

Lee la salida de la actualización, no solo el código de salida. APT nombra el repositorio cuyos metadatos fallaron, y ese nombre es la frontera que hay que investigar. Un repositorio marcado como de confianza sin verificación de firma, o una anulación para un repositorio inseguro, es una decisión de configuración que alguien tomó y debería poder explicar.

La frescura es otra vez una propiedad aparte. Un archivo de metadatos firmado válidamente puede ser más antiguo que el que viste la semana pasada, por eso los metadatos de publicación llevan una caducidad y por eso un problema de reloj en el cliente puede producir errores de verificación que parecen problemas de clave.

Qué comprueba dnf5 por separado

El lado RPM expone dos interruptores distintos, y confundirlos produce la misma clase de error en la dirección contraria. Uno controla si los archivos de paquete deben llevar una firma válida; el otro controla si los metadatos del repositorio deben estar firmados. Pueden ajustarse de forma independiente, y un sistema puede ser estricto con uno y permisivo con el otro.

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

La consulta del paquete muestra cómo son los metadatos de firma de la copia instalada, lo que es una comprobación de realidad útil frente a un archivo de configuración que afirma rigor. Lo que no te dice es la política soportada de la distribución, y es la que deberías seguir en lugar de una instrucción genérica de «activa GPG» de un foro.

Donde los dos gestores difieren, la diferencia es arquitectónica y no una señal de que uno sea más débil. Ambos autentican el contenido del publicador; sitúan la firma en puntos distintos de la cadena.

Qué añade el túnel y qué no

Una VPN puede aportar una ruta necesaria, mantener el tráfico de actualizaciones fuera de una red de acceso no confiable y reducir lo que ve un observador local. Son beneficios operativos reales, y ninguno de ellos es autenticación del publicador.

HTTPS añade su propia garantía, y es más estrecha de lo que parece. Autentica el extremo TLS al que te conectaste. Si ese extremo es un espejo, has autenticado el espejo, no el contenido del archivo que sirve. Este es precisamente el caso para el que existe la cadena de metadatos firmados.

Ninguno de los dos controles promete disponibilidad. Una red puede negar la entrega, y un objeto autenticado no es automáticamente el más reciente. Usa la política de frescura del propio gestor de paquetes en lugar de inferirla de la presencia de un icono de candado.

Diagnostica la frontera que falló

Nombra la etapa antes de cambiar nada: resolución DNS, el proxy o la ruta, la identidad del extremo TLS, la autenticación del archivo, las comprobaciones de firma del paquete o la instalación. Cada una tiene una forma de error y un propietario distintos.

Reparar una ruta de red nunca debería implicar declarar de confianza una clave de firma desconocida, ignorar certificados o aceptar una configuración de repositorio que no pediste. Si una clave realmente rotó, la distribución o el propietario del repositorio publican la clave nueva por un canal que puedes verificar, y esa es la corrección que hay que aplicar.

Anota qué frontera falló y quién es su dueño. El próximo fallo de actualización estará en otra frontera, y tener la lista lo convierte en un diagnóstico de cinco minutos en lugar de otra discusión sobre si el túnel hace seguras las actualizaciones.