A atualização do apt falha com NO_PUBKEY após adicionar um repositório VPN

A fonte apt do seu fornecedor de VPN estragou o gestor de pacotes, e a correção é uma decisão, não um comando. NO_PUBKEY, ou uma queixa de que o repositório não tem ficheiro Release, significa que o apt recusou confiar nessa fonte, pelo que cada operação de pacotes posterior continua a imprimir o mesmo aviso. O túnel em si é provavelmente inocente. Responda a três perguntas sobre se ainda quer essa fonte, e a reparação correta segue quase mecanicamente.

Primeiro, coloque a falha na categoria certa

Uma falha de confiança nomeia o ficheiro de origem e ou a chave em falta ou o ficheiro Release ausente. Uma falha de transporte é diferente: erros de certificado TLS, ligação recusada, tempos limite ou um proxy que recusa CONNECT. Essa distinção decide qual artigo está a ler, porque uma VPN que interceta TLS ou bloqueia o anfitrião do fornecedor produz erros de transporte, não erros de assinatura.

Execute sudo apt update sozinho e leia o fim, ignorando os resultados em cache acima. A linha que importa nomeia /etc/apt/sources.list.d/ e diz-lhe que ficheiro abrir.

Se a falha surge depois de o túnel subir, teste com o túnel em baixo e com o DNS resolvido pelo resolvedor do sistema. Uma fonte que funciona sem a VPN é uma questão de encaminhamento ou interceção, e nenhuma gestão de chaves o resolve.

Três perguntas que escolhem o caminho

Ainda instala ou atualiza pacotes a partir desta fonte? Se o cliente está em uso ativo, repare a confiança. Se instalou o cliente uma vez e agora importa um perfil simples no NetworkManager, a fonte é peso morto e removê-la é a reparação honesta.

Segundo, o fornecedor publica uma chave e uma impressão digital que possa verificar fora do canal? Terceiro, quem gere as chaves neste anfitrião: a distribuição ou você? Uma fonte assinada com uma chave que não pode verificar é uma autoridade de atualização que não deve conceder.

Responder não à primeira pergunta termina a análise. Responder sim aos três pontos aponta para a reparação com signed-by, a única disposição que funciona e continua auditável. Misturar os dois caminhos, mantendo a fonte e forçando-a, é a única opção que vale a pena excluir explicitamente.

Porque é que trusted=yes parece uma correção e não é

A página do manual do sources.list é direta quanto a isso. Definir a opção Trusted como yes diz ao apt para aceitar a fonte mesmo quando falha a autenticação, o que desliga o apt-secure para esse repositório. A página reserva isso para um contexto local, se é que é usado.

Não é uma versão mais estreita de confiar no fornecedor. Remove a questão de quem assinou o índice, pelo que qualquer pessoa que possa responder por esse nome de anfitrião pode entregar à sua máquina pacotes que se instalam como root.

Caminho de reparação: obtenha a chave e depois fixe-a

Obtenha a chave no local que o fornecedor documenta e desarmure-a para um porta-chaves gerido pelo administrador, depois aponte a linha do repositório para esse ficheiro para que a confiança não possa derivar.

1. Leia a linha que falha para obter o ID da chave e o nome do ficheiro de origem.
2. Transfira a chave do fornecedor blindada em ASCII e execute gpg --dearmor para /etc/apt/keyrings/vendor-name.gpg.
3. Adicione [signed-by=/etc/apt/keyrings/vendor-name.gpg] à entrada no ficheiro .list desse fornecedor.
4. Execute sudo apt update e confirme que a fonte obtém um índice em vez de repetir o aviso de assinatura.

Prefira /usr/share/keyrings para chaves que chegam com um pacote e /etc/apt/keyrings para chaves que coloca à mão. A divisão não é cosmética: diz ao administrador seguinte que chaves sobreviverão a uma atualização de pacote e quais precisam de uma pessoa.

Verifique a impressão digital contra o valor publicado pelo fornecedor antes de confiar nela. Um ID de chave colado de uma publicação de fórum é a forma como uma máquina acaba por confiar numa autoridade de atualização que ninguém consegue nomear.

Caminho de remoção, e porque é que o erro pode voltar

Veja o que o instalador escreveu realmente, porque vários ficheiros podem mencionar o mesmo fornecedor e um deles é normalmente uma cópia deixada para trás.

grep -r . /etc/apt/sources.list.d/
sudo rm /etc/apt/sources.list.d/vendor.list

O apt só lê ficheiros .list e .sources desse diretório, pelo que uma cópia .save ou .distUpgrade já é ignorada; apagá-la de qualquer forma impede um leitor posterior de a restaurar por acidente. Remover a fonte não desinstala nada, e o apt pode então descrever o pacote VPN instalado como instalado localmente ou já indisponível, o que é uma mensagem de estado do pacote e não o regresso do erro de confiança.

O caso recorrente é orientação mais antiga que instalava chaves com apt-key no anel de confiança global. Esse caminho está obsoleto, e uma atualização de versão pode deixar a chave caída ou simplesmente não consultada, e é exatamente por isso que um erro que esteve silencioso durante um ano aparece na semana em que atualiza. Verifique /etc/apt/trusted.gpg.d/, e depois mova a decisão de confiança para a linha do repositório onde pertence. Se o fornecedor ainda imprime instruções de apt-key, use signed-by de qualquer forma; é a disposição que o manual documenta, e a que sobrevive a uma atualização.