Por que a página man apt-key aconselha contra o uso de seu comando add?

Question

A página do manual do Ubuntu para o apt-key inclui a seguinte nota sobre apt-key add :

Note: Instead of using this command a keyring should be placed directly in the /etc/apt/trusted.gpg.d/ directory with a descriptive name and either "gpg" or "asc" as file extension.

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

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

Answer 1

Esses projetos têm instruções desatualizadas. Eu sei disso porque eu 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 não tem nada a ver com os diretórios .d e tem mais a ver com a prevenção de uma vulnerabilidade entre sites no APT. O sistema mais antigo usava arquivos de chaveiro separados por conveniência, mas isso agora é uma necessidade de segurança; sua segurança

Esta é a vulnerabilidade. Considere dois publicadores de repositórios, A e B. No mundo do Debian 8 e antes, as duas chaves dos editores estavam no único chaveiro global nas máquinas dos usuários. Se a editora A pudesse de alguma forma arranjar para suplantar o repositório do site WWW da editora B, então A poderia publicar pacotes subversivos, assinados com a própria chave de A , que a APT aceitaria e instalaria alegremente. A chave de A é, afinal, confiável globalmente para todos os repositórios.

A atenuação é para os usuários usarem chaveiros separados para editores individuais e fazer referência a essas chaves com Signed-By configurações individuais em suas definições de repositório. Especificamente, a chave do editor A é usada apenas no Signed-By do repositório A e a chave do editor B é usada apenas no Signed-By do repositório B. Desta forma, se o editor A suplantar o repositório do editor B, o APT não aceitará os pacotes subversivos a partir dele, uma vez que eles e o repositório são assinados pela chave do editor A, não pelos editores B.

O mecanismo /etc/apt/trusted.gpg.d na mão é a casa meio defeituosa de um Pobre Homem mais velho em relação a isso, em 2005, o que não é bom o suficiente. Ele configura o chaveiro em um arquivo separado, para que possa ser empacotado e instalado em apenas uma etapa por um gerenciador de pacotes (ou baixado com fetch / curl / wget ) como qualquer outro arquivo. (O gerenciador de pacotes lida com o fato de o pacote especial este-é-meu-repositório-chaveiro do editor A não ser instalado nos editores B, da maneira normal em lidar com conflitos entre pacotes em geral.) adiciona-o ao conjunto de chaves que é globalmente confiável para todos os repositórios. O mecanismo completo que existe agora usa arquivos de chaveiro separados, não globalmente confiáveis, em /usr/share/keyrings/ .

Minhas instruções já estão lá. ☺ Existem movimentos para mover os repositórios do Debian para este mecanismo, para que eles não usem mais chaves globalmente confiáveis. Você pode querer falar com os "mais projetos" que 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 (2017-05-02). Envie as chaves específicas da versão separadamente fora de /etc/apt/trusted.gpg.d/ . Bug do Debian # 861695.
• Daniel Kahn Gillmor (2017-07-27). debian sources.list entradas devem ter opções assinadas apontando para chaves específicas . Bug do Debian # 877012.
• "Sources.list entry" . Instruções para se conectar a um repositório de terceiros . Wiki do Debian. 2018.
• Por que não é um risco de segurança adicionar a sources.list?
• Debian 9, APT e "GPG error: ... InRelease: as seguintes assinaturas eram inválidas:"

Answer 2

apt-key del recebe o keyid , que é um hash sem significado 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 de chaves confiáveis que são instalados como parte de um pacote debian. Eu acho que também pode ser melhor quando você instalou manualmente um arquivo de chave.

No novo mecanismo que está 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 deixará automaticamente de permitir a chave configurada para esse repo (a menos que também seja usado por outro repo).

Não sei como aproveitar o novo mecanismo de segurança. Eu apenas suponho 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 : -).