HTTPS e uma VPN não autenticam o pacote que você instala

Uma atualização falha, e a sugestão na thread segue uma linha conhecida: o tráfego passa por uma VPN, então o download deve ser confiável, e a verificação de assinatura é relaxada para contornar o erro. Duas ideias separadas foram fundidas numa única frase. A criptografia protege um caminho entre extremos; a autenticação decide se os bytes vieram do publicador que você pretendia. Um túnel fornece a primeira e não diz nada sobre a segunda.

O sintoma costuma ser um erro de verificação num host, num repositório, enquanto todo o resto é atualizado normalmente. Essa forma já diz que o caminho de rede funciona e que a discordância é sobre confiança.

Dois controles que respondem a perguntas diferentes

A segurança do transporte responde quem está do outro lado desta conexão e se alguém no caminho pode lê-la ou modificá-la. A autenticação do pacote responde se este artefato foi publicado pela autoridade que você configurou, e precisa sobreviver a um download através de um espelho que você não controla.

Essas perguntas só se sobrepõem nas bordas. Um certificado correto num espelho prova que o espelho é o espelho; não prova que o espelho contém conteúdo do publicador sem modificação. Um pacote assinado prova que o publicador o assinou; não diz que a rede entregou a versão mais recente nem que o repositório que você indicou é o aprovado pela sua organização.

O modo de falha que as pessoas criam ao desativar verificações é uma perda permanente da segunda garantia, em troca de um download bem-sucedido. Essa troca é invisível até o dia em que importa.

O que o apt realmente autentica

O modelo do APT é uma cadeia de arquivo autenticada. Os metadados de publicação assinados levam, por soma de verificação, aos índices de pacotes, e esses índices levam, por soma de verificação, aos arquivos individuais de pacote. É a verificação da cadeia que torna um espelho não confiável mas utilizável: o espelho pode servir o que quiser, e a assinatura dos metadados decide se o APT o aceita.

Isso deliberadamente não é o mesmo que verificar a assinatura de um mantenedor em cada pacote instalado, e a distinção explica por que «o pacote está assinado» e «o arquivo está autenticado» são usados indistintamente em relatórios de bug quando significam coisas diferentes.

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

Leia a saída da atualização, não apenas o código de saída. O APT nomeia o repositório cujos metadados falharam, e esse nome é a fronteira a investigar. Um repositório marcado como confiável sem verificação de assinatura, ou uma substituição para repositório inseguro, é uma decisão de configuração que alguém tomou e deveria conseguir explicar.

A frescura é novamente uma propriedade separada. Um arquivo de metadados assinado validamente pode ser mais antigo que o que você viu na semana passada, por isso os metadados de publicação trazem uma validade e por isso um problema de relógio no cliente pode produzir erros de verificação que parecem problemas de chave.

O que o dnf5 verifica separadamente

O lado RPM expõe dois interruptores distintos, e confundi-los produz a mesma classe de erro na direção oposta. Um controla se os arquivos de pacote devem carregar uma assinatura válida; o outro controla se os metadados do repositório devem estar assinados. Podem ser definidos de forma independente, e um sistema pode ser rigoroso num e permissivo no outro.

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

A consulta do pacote mostra como são os metadados de assinatura da cópia instalada, o que é uma verificação de realidade útil contra um arquivo de configuração que afirma rigor. O que ela não diz é a política suportada da distribuição, e é essa que você deveria seguir em vez de uma instrução genérica de «ative o GPG» de um fórum.

Onde os dois gerenciadores diferem, a diferença é arquitetural e não um sinal de que um seja mais fraco. Ambos autenticam o conteúdo do publicador; eles colocam a assinatura em pontos diferentes da cadeia.

O que o túnel acrescenta e o que não acrescenta

Uma VPN pode fornecer uma rota necessária, manter o tráfego de atualização fora de uma rede de acesso não confiável e reduzir o que um observador local vê. São benefícios operacionais reais, e nenhum deles é autenticação do publicador.

O HTTPS acrescenta a sua própria garantia, e ela é mais estreita do que parece. Ele autentica o extremo TLS ao qual você se conectou. Se esse extremo é um espelho, você autenticou o espelho, não o conteúdo do arquivo que ele serve. Este é precisamente o caso para o qual existe a cadeia de metadados assinados.

Nenhum dos controles promete disponibilidade. Uma rede pode negar a entrega, e um objeto autenticado não é automaticamente o mais recente. Use a política de frescura do próprio gerenciador de pacotes em vez de inferi-la da presença de um ícone de cadeado.

Diagnostique a fronteira que falhou

Nomeie a etapa antes de mudar qualquer coisa: resolução DNS, o proxy ou a rota, a identidade do extremo TLS, a autenticação do arquivo, as verificações de assinatura do pacote ou a instalação. Cada uma tem uma forma de erro e um proprietário distintos.

Reparar um caminho de rede nunca deveria implicar declarar confiável uma chave de assinatura desconhecida, ignorar certificados ou aceitar uma configuração de repositório que você não pediu. Se uma chave realmente rotou, a distribuição ou o proprietário do repositório publicam a chave nova por um canal que você pode verificar, e essa é a correção a aplicar.

Anote qual fronteira falhou e quem é o dono dela. A próxima falha de atualização estará noutra fronteira, e ter a lista faz dela um diagnóstico de cinco minutos em vez de outra discussão sobre se o túnel torna as atualizações seguras.