Esta ainda é uma questão bastante ampla.
Verificando pacotes
O conteúdo dos espelhos é assinado usando chaves PGP, direta ou indiretamente. Começando na "raiz" de uma distribuição Debian:
-
Releaseassinado com uma assinatura separada emRelease.gpg, contém os hashes (MD5, SHA1, SHA256) de todos os índices de pacote e hashes do instalador; - os índices de pacote ( por exemplo ,
binary-amd64) contém os hashes (MD5 e SHA256) dos pacotes.
Os hashes e as assinaturas são verificados por ferramentas como apt-get usando chaves PGP armazenadas no sistema (gerenciadas por apt-key ). Assim, enquanto o sistema de recebimento é o som, por padrão nenhum pacote pode ser instalado a partir dos repositórios Debian se ele não tiver sido assinado (indiretamente) pela chave PGP de arquivamento. Qualquer intruso nos espelhos não poderá substituir binários se eles também não tiverem controle da chave PGP relevante.
Controlando os espelhos
Isso significa que comprometer o arquivo não é suficiente para comprometer os sistemas do usuário final; você também precisa comprometer uma chave PGP na qual esses sistemas já confiam. (Um corolário disto é que adicionar uma chave a um sistema Debian não é algo que deva ser tomado de ânimo leve.) Isso resolve sua primeira questão até certo ponto, já que a segurança do arquivo não é tão importante. No entanto, os sistemas críticos (onde a assinatura acontece) são estritamente monitorados e supervisionados, e muito poucas pessoas têm acesso a eles.
Expectativas do mantenedor
Garantir que os pacotes sejam "na verdade, aqueles que os mantenedores pensam que são" está um pouco mais envolvido. Este é o caminho percorrido por um pacote:
- o pacote é preparado por um mantenedor, e assinado com uma chave no chaveiro Debian ( ie uma chave pertencente a um desenvolvedor Debian, ou um mantenedor Debian, carregado no servidor de chaves Debian mesclado pela equipe de manutenção do keyring);
- o pacote assinado é carregado no arquivo, onde é verificado (entre outras coisas, as chaves usadas devem estar no chaveiro atual e não devem ter expirado, as assinaturas devem ser válidas e se o pacote foi assinado por um DM, esse DM deve ter as permissões relevantes para o pacote);
- todos os binários enviados são enviados para o arquivo final como estão (estou simplificando um pouco aqui, mas esse é o efeito);
- quaisquer binários perdidos são construídos por um buildd e assinados pela chave PGP do buildd, e enviados para o arquivo final (que sabe quais chaves buildd são válidas e verifica arquivos contra elas);
- todas essas atualizações são eventualmente enviadas para a rede de espelhamento, com as atualizações de índice apropriadas (que são assinadas conforme descrito acima).
Se o mantenedor fizer upload de binários junto com a origem do pacote, esses arquivos serão exibidos (por enquanto). Como o upload de binários agora é opcional, é cada vez mais comum ignorá-los e, eventualmente, os binários enviados serão descartados. (Este sempre foi o caso no Ubuntu). Se os outros binários correspondem às expectativas do mantenedor depende da rede buildd; Portanto, os buildds também são sistemas críticos, sob supervisão rigorosa e com pouco acesso humano. Como todos os artefatos são assinados, sempre é possível verificar a integridade dos arquivos: primeiro contra a chave do mantenedor, depois contra as chaves dos buildds e, finalmente, contra a chave do arquivo morto.
Como apontado por plugwash , as assinaturas originais não estão disponíveis nos espelhos, e qualquer DD pode faça o upload de um binário ausente. As assinaturas originais podem ser recuperadas dos arquivos debian-devel-changes .
Em resumo , embora o sistema atual não seja perfeito, ele fornece rastreabilidade para todos os arquivos que você pode baixar dos espelhos. Há uma série de esforços para melhorar a situação: compilações reproduzíveis (que permitirão a verificação independente da correspondência dos binários com a fonte publicada), eliminando binários fornecidos pelo mantenedor ...