7.4. Infrastructure de construction de sécurité Debian
Comme Debian prend actuellement en charge un grand nombre d'architectures, les administrateurs se demandent parfois si une architecture donnée pourrait prendre plus de temps pour recevoir des mises à jour de sécurité qu'une autre. En fait, à part dans de rares circonstances, les mises à jour sont disponibles pour toutes les architectures en même temps.
Les paquets de l'archive de sécurité sont construits automatiquement, tout comme l'archive classique. Cependant, les mises à jour de sécurité sont un petit peu différentes des envois normaux par les responsables de paquets car, dans certains cas, avant d'être publiées, elles doivent attendre de pouvoir être plus testées, qu'une alerte soit rédigée ou attendre une semaine ou plus pour éviter de publier le défaut jusqu'à ce que tous les distributeurs aient eu une chance raisonnable de le corriger.
L'archive d'envoi de sécurité fonctionne donc de la façon suivante :
quelqu'un trouve un problème de sécurité ;
quelqu'un corrige le problème et fait un envoi vers incoming de security-master.debian.org (ce quelqu'un est habituellement un membre de l'équipe de sécurité, mais ce peut aussi être un responsable de paquet avec un correctif approprié qui a contacté l'équipe de sécurité auparavant). Le journal de modifications contient une cible de distribution testing-security ou stable-security ;
l'envoi est vérifié et traité par un système Debian et déplacé dans queue/accepted et le service d'empaquetage est prévenu. Les fichiers à cet endroit sont accessibles par l'équipe de sécurité et (de façon un peu indirecte) par les service d'empaquetage ;
les serveurs d'empaquetage activés pour la sécurité récupèrent le paquet source (en priorité par rapport aux constructions courantes), le construisent et envoient les journaux à l'équipe de sécurité ;
l'équipe de sécurité répond aux journaux et les paquets nouvellement construits sont envoyés vers queue/unchecked, où ils sont traités par un système Debian et déplacés dans queue/accepted ;
quand l'équipe de sécurité trouve les paquets acceptables (c'est-à-dire qu'ils sont correctement construits pour toutes les architectures pertinentes et corrigent le trou de sécurité sans introduire de nouveau problème par eux-mêmes), un script est exécuté qui :
installe le paquet dans l'archive de sécurité ;
met à jour les fichiers Packages, Sources et Release de security.debian.org de la façon habituelle (dpkg-scanpackages, dpkg-scansources, etc.) ;
met en place un modèle d'alerte que l'équipe de sécurité peut compléter ;
fait suivre les paquets vers le proposed-updates approprié pour qu'il soit intégré à l'archive réelle dès que possible.
Cette procédure, auparavant réalisée à la main, a été testée et mise en place pendant l'étape de gel de Debian 3.0 Woody (juillet 2002). Grâce à cette architecture, l'équipe de sécurité a pu avoir des paquets mis à jour pour les problèmes d'Apache et d'OpenSSH pour toutes les architectures prises en charge (presque vingt) en moins d'un jour.
7.4.1. Le guide du développeur pour les mises à jour de sécurité
