A página de manual do Ubuntu para o apt-key inclui a seguinte observação sobre apt-key add:

Nota: Em vez de usar este comando, um chaveiro deve ser colocado diretamente no diretório /etc/apt/trusted.gpg.d/ com um nome descritivo e "gpg" ou "asc" como extensão de arquivo.

Acho que nunca vi esse conselho em nenhum outro lugar. A maioria dos projetos que hospedam seus próprios repositórios diz para baixar o arquivo-chave e adicioná-lo apt-key.

1. Qual é a motivação por trás deste conselho?
2. Isso é um Ubuntu-ism ou se aplica a qualquer distribuição baseada em APT?

Esses projetos têm instruções desatualizadas. Eu sei disso porque publico um repositório Debian e atualizei minhas instruções quando descobri as mudanças no Debian 9 APT. De fato, esta parte do manual está desatualizada, pois é o diretório errado.

Isso realmente não tem a ver com .ddiretórios e mais com a prevenção de uma vulnerabilidade entre sites no APT. O sistema antigo usava arquivos de chaveiro separados por conveniência, mas agora é uma necessidade de segurança; sua segurança.

Essa é a vulnerabilidade. Considere dois editores de repositório, A e B. No mundo do Debian 8 e antes, as chaves de ambos os editores foram inseridas no chaveiro global único nas máquinas dos usuários. Se o editor A pudesse, de alguma forma, providenciar a substituição do site WWW do repositório B, então A poderia publicar pacotes subversivos, assinados com a própria chave de A , que o APT aceitaria e instalaria com prazer. Afinal, a chave de A é confiável globalmente para todos os repositórios.

A atenuação é para que os usuários usem chaveiros separados para editores individuais e faça referência a esses chaveiros com Signed-Byconfigurações individuais em suas definições de repositório. Especificamente, a chave do editor A é usada apenas no Signed-Byrepositório A e a chave do editor B é usada apenas no Signed-Byrepositório B. Dessa forma, se o editor A substituir o repositório do editor B, o APT não aceitará os pacotes subversivos, pois eles e os O repositório é assinado pela chave do editor A e não pelo editor B.

O /etc/apt/trusted.gpg.dmecanismo em questão é um meio-caminho um tanto defeituoso de um velho Pobre para isso, já em 2005, mais ou menos, isso não é o bastante. Ele configura o chaveiro em um arquivo separado, para que possa ser empacotado e instalado em uma única etapa por um gerenciador de pacotes (ou baixado com fetch/ curl/ wget) como qualquer outro arquivo. (O gerenciador de pacotes lida com a prevenção de que o pacote especial este é meu repositório de chaves do editor A seja instalado sobre o editor B, da maneira normal como ele lida com conflitos de arquivos entre pacotes em geral.) Mas ainda o adiciona ao conjunto de chaves globalmente confiável para todos os repositórios. O mecanismo completo que existe agora usa arquivos de chaveiro separados, não confiáveis ​​globalmente /usr/share/keyrings/.

Minhas instruções já estão lá. Moves Existem movimentos em andamento para mover os repositórios do Debian para esse mecanismo, para que eles não usem mais chaves confiáveis ​​globalmente. Você pode querer falar com a "maioria dos projetos" que você encontrou. Afinal, eles estão instruindo você a entregar o acesso global ao APT em sua máquina para eles.

Leitura adicional

• Daniel Kahn Gillmor (02-05-2017). Envie as chaves específicas da versão separadamente para fora de/etc/apt/trusted.gpg.d/ . Bug do Debian # 861695.
• Daniel Kahn Gillmor (27/07/2017). entradas debian sources.listdevem ter opções de login apontando para chaves específicas . Bug no Debian # 877012.
• "Entrada Sources.list" . Instruções para conectar-se a um repositório de terceiros . Wiki do Debian. 2018.
• Por que não é um risco de segurança adicionar ao sources.list?
• Debian 9, APT e "Erro GPG: ... InRelease: As seguintes assinaturas eram inválidas:"

apt-key delpega o keyid, que é um hash sem sentido da chave.

É mais simples se você pode desinstalar chaves usando um nome significativo ... como um nome de arquivo.

Como o JdeBP diz, isso funciona muito bem com arquivos-chave confiáveis ​​que são instalados como parte de um pacote debian. Eu acho que também pode ser melhor quando você instala manualmente um arquivo de chave.

No novo mecanismo atualmente em "teste inicial", isso é ainda mais simplificado. Você só precisa remover / desativar uma coisa: o repositório (em sources.list / sources.list.d). Isso interromperá automaticamente a permissão da chave configurada para esse repo (a menos que ela também tenha sido usada por outro repo).

Não sei como tirar proveito do novo mecanismo de segurança. Apenas presumo que preciso confiar em alguém se eu usar o pacote deles. O processo de instalação do pacote ainda está sendo executado como root:-).