Tout allait bien jusqu’au jour où Kali s’est mis à bouder les mises à jour. Derrière l’erreur de signature qui bloque le système, pas de bug complexe ni de faille de sécurité. OffSec a juste perdu sa clé, et c’est à vous de réparer.
Vous pensiez être seul à galérer sur Kali depuis quelques jours ? Détrompez-vous. Voilà un moment, maintenant, que la commande apt update refuse de coopérer. Et contrairement à ce que l’on pourrait croire, le problème est parfaitement identifié… et assumé. Le système de mises à jour est officiellement bloqué, non pas à cause d’un bug de configuration ou d’un souci réseau, mais bien parce qu’Offensive Security, qui maintient le projet, a perdu une clé de signature du dépôt officiel. Une petite négligence pour un gros impact, qui, sans intervention manuelle de votre part, empêche irrémédiablement votre système de récupérer les nouvelles updates.
Une clé perdue, un dépôt gelé, et des mises à jour KO
Depuis la mi-avril, les dépôts de Kali Linux étaient à l’arrêt, mais vous ne l’aviez probablement pas remarqué jusqu’à aujourd’hui. Et pour cause, cette interruption n’avait jusque-là aucune conséquence visible.
Mais en ce début de semaine, Offensive Security a remis en ligne le dépôt, et depuis, les systèmes commencent à réagir. Toutes les tentatives de mise à jour se soldent par un échec, accompagnées d’un message d’erreur sans équivoque : une clé GPG nécessaire à la vérification de l’authenticité des paquets est manquante. Sans elle, apt considère les paquets comme non fiables, et bloque l’opération.
Dans un billet de blog, OffSec a finalement reconnu avoir perdu l’accès à cette clé. Comme elle n’a pas été compromise, elle n’a pas été révoquée, mais elle ne peut plus être utilisée pour signer quoi que ce soit.
Une nouvelle clé, identifiée sous l’empreinte ED65462EC8D5E4C5, a donc été générée, signée par les développeurs du projet, et intégrée au fichier archive-keyring.gpg mis à disposition en ligne. Pour rétablir le fonctionnement du système de mises à jour, il faut la télécharger manuellement et la placer dans le répertoire /usr/share/keyrings/. La manipulation est simple, mais elle n’est pas automatisée, et rien dans l’interface ne signale qu’une intervention est nécessaire.
Pour les allergiques aux lignes de commande, et pour éviter que ce blocage ne concerne aussi les nouvelles installations, des ISO corrigées sont déjà disponibles (2025.1c). Elles reprennent le contenu des versions précédentes, avec la nouvelle clé déjà intégrée. Les autres déclinaisons de Kali – NetHunter, les machines virtuelles, les versions Docker ou les environnements WSL – ont également été mises à jour dans la foulée.
Un incident mineur, mais un rappel utile sur les coulisses de la sécurité open source
Ce genre d’incident fait toujours sourire, surtout quand l’équipe elle-même reconnaît que c’est entièrement sa faute. Dans l’absolu, la perte d’une clé de signature n’a rien de dramatique en soi. Il n’y a eu ni brèche, ni fuite de données, ni compromission de l’intégrité des paquets. Les utilisateurs et utilisatrices ne risquent rien, si ce n’est d’avoir à effectuer une manipulation un peu technique pour remettre leur système en état. Mais il a au moins le mérite de rappeler comment fonctionne une distribution Linux, et pourquoi tout repose sur un trousseau de clés.
Dans l'univers Linux, chaque paquet téléchargé est accompagné d’une signature cryptographique, apposée par une clé privée que seul le mainteneur du dépôt est censé posséder. Cette signature est vérifiée localement à l’aide d’une clé publique stockée dans un keyring. Si cette clé est absente, expirée, ou inaccessible, la chaîne de confiance se brise, et le système refuse tout net de poursuivre. Un comportement qui peut sembler strict, mais qui garantit que personne ne peut, en théorie, injecter du code malveillant dans les dépôts sans que cela ne soit immédiatement détecté.
Ce n’est d’ailleurs pas la première fois que Kali doit faire face à ce type de situation. En 2018 déjà, les équipes d’OffSec avaient oublié de renouveler une clé arrivée à expiration, provoquant là aussi des erreurs d’updates. La réponse avait été la même, avec une mise à jour du keyring à effectuer à la main. Une solution tout à fait acceptable, mais qui repose sur un prérequis, à savoir être informé du problème et disposer des connaissances suffisantes pour y remédier.
Pour des environnements axés sur la sécurité, cette exigence peut paraître paradoxale. Mais elle reflète aussi une réalité propre à l’open source : les projets sont souvent maintenus par des équipes limitées, avec leurs propres méthodes, contraintes et oublis. Et dans ce cadre, la transparence reste la meilleure réponse possible. OffSec n’a pas tenté de dissimuler l’incident, n’a pas cherché à minimiser son impact, et a fourni les outils nécessaires pour reprendre la main rapidement. Ce n’est pas parfait, mais c’est ce qu’on peut attendre, au minimum, d’une distribution tournée vers la sécurité.
Source : Offensive Security
03 mars 2025 à 10h05
