Réponses:
Le contenu des miroirs est signé à l'aide de clés PGP, directement ou indirectement. À partir de la "racine" d'une distribution Debian:
Release
, signé avec une signature détachée dans Release.gpg
, contient les hachages (MD5, SHA1, SHA256) de tous les index de packages et hachages d'installation ( InRelease
combine désormais les deux);binary-amd64
) contiennent les hash (MD5 et SHA256) des paquets.Les hachages et les signatures sont vérifiés par des outils tels que l' apt-get
utilisation de clés PGP stockées sur le système (gérées par apt-key
). Donc, tant que le système de réception est sain, par défaut aucun paquet ne peut être installé à partir des archives Debian s'il n'a pas été signé (indirectement) par la clé PGP de l'archive. Les intrus sur les miroirs ne pourraient pas remplacer les binaires s'ils n'avaient pas également le contrôle de la clé PGP appropriée.
Cela signifie que compromettre l'archive n'est pas suffisant pour compromettre réellement les systèmes des utilisateurs finaux; vous devez également compromettre une clé PGP à laquelle ces systèmes font déjà confiance. (Un corollaire à cela est que l'ajout d'une clé à un système Debian n'est pas quelque chose à prendre à la légère.) Cela répond dans une certaine mesure à votre première question, car la sécurité des archives n'a pas tellement d'importance. Néanmoins, les systèmes critiques (où la signature a lieu) sont strictement surveillés et supervisés, et très peu de personnes y ont accès.
S'assurer que les packages sont «en fait ceux que les responsables pensent qu'ils sont» est un peu plus complexe. Voici le chemin emprunté par un package:
Si le responsable télécharge des fichiers binaires avec la source du package, ce sont les fichiers qui finissent par être servis (pour le moment). Étant donné que le téléchargement de fichiers binaires est désormais facultatif, il est de plus en plus courant de les ignorer, et les fichiers binaires téléchargés seront finalement supprimés. (Cela a toujours été le cas dans Ubuntu.) Le fait que les autres binaires correspondent aux attentes du responsable dépend du réseau buildd; les buildds sont donc aussi des systèmes critiques, sous étroite surveillance et avec peu d'accès humain. Puisque tous les artefacts sont signés, il est toujours possible de vérifier l'intégrité des fichiers: d'abord contre la clé du responsable, puis contre les clés des buildds, et enfin contre la clé de l'archive.
Comme indiqué par plugwash , les signatures originales ne sont pas disponibles sur les miroirs, et tout DD peut télécharger un binaire manquant. Les signatures originales peuvent être récupérées dans les archives debian-devel-changes .
En résumé , bien que le système actuel ne soit pas parfait, il offre une traçabilité pour tous les fichiers que vous pouvez télécharger à partir des miroirs. Il y a un certain nombre d'efforts pour améliorer la situation: versions reproductibles (qui permettront une vérification indépendante de la correspondance des binaires avec la source publiée), suppression des binaires fournis par le responsable ...
apt-get
vérifient les packages en utilisant ces clés locales pré-intégrées, car il leur fait confiance?
debian-archive-keyring
colis. apt-get
vérifie les Release
fichiers à l'aide de ces clés et les packages à l'aide des hachages contenus dans les fichiers Release
et Packages
.