Início / unix / Perguntas / 463072
Accepted
Andrew
Asked: 2018-08-17 13:19:17 +0800 CST

Por que a página de manual apt-key desaconselha o uso de seu comando add?

  • 772

A página de manual do Ubuntu para apt-key inclui a seguinte nota 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 seu arquivo de chave e adicioná-lo com apt-key.

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

2 respostas

  1. Best Answer

    Esses projetos têm instruções desatualizadas. Eu sei disso porque publiquei 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 a ver com .ddiretórios e mais com a prevenção de uma vulnerabilidade entre sites no APT. O sistema mais antigo usava arquivos de chaveiro separados por conveniência, mas agora isso é 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 anteriores, as chaves de ambos os editores ficavam no único chaveiro global nas máquinas dos usuários. Se o publicador A pudesse, de alguma forma, suplantar o repositório do site WWW do publicador B, então A poderia publicar pacotes subversivos, assinados com a própria chave de A , que o APT aceitaria e instalaria de bom grado. A chave de A é, afinal, confiável globalmente para todos os repositórios.

    A mitigação é para que os usuários usem keyrings separados para editores individuais e façam referência a esses keyrings com configurações individuais Signed-Byem 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 suplantar o repositório do editor B, o APT não aceitará os pacotes subversivos dele, pois eles e o repositório são assinados pela chave do editor A e não pelo editor B.

    O /etc/apt/trusted.gpg.dmecanismo em questão é um meio-termo um tanto falho de um Homem Pobre mais velho para isso, de volta em 2005 ou algo assim, que não é bom o suficiente. 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 evita que o pacote especial this-is-my-repository-keyring do editor A seja instalado sobre o do editor B, da maneira normal que lida com conflitos de arquivo entre pacotes em geral.) Mas ainda o adiciona 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 confiáveis ​​globalmente no formato /usr/share/keyrings/.

    Minhas instruções já estão lá. ☺ Há movimentos em andamento para mover os próprios repositórios do Debian para este mecanismo, para que eles também não usem chaves globalmente confiáveis. Você pode querer ter uma palavra com aqueles "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

    • 26

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

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

    Como o JdeBP diz, isso funciona bem com arquivos de chave 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/desabilitar uma coisa: o repositório (em sources.list / sources.list.d). Isso interromperá automaticamente a permissão da chave configurada para esse repositório (a menos que também tenha sido usada por outro repositório).

    Não sei como aproveitar o novo mecanismo de segurança. Eu apenas assumo que preciso confiar em alguém se eu usar seu pacote. O processo de instalação do pacote ainda está sendo executado como root:-).

    • 1

relate perguntas