L'incident OpenMandriva ne vaut pas seulement comme drame de distribution Linux. La leçon utile est plus terne et plus importante: l'open source repose sur la confiance, mais les utilisateurs installent le résultat comme une infrastructure.

Pipeline de paquets open source avec clés d’accès journal d’audit et coffre de sauvegarde

Le 8 juillet, OpenMandriva a publié un message de forum sur plusieurs perturbations et a parlé d'une tentative de sabotage de la distribution. Selon le projet, l'ancien contributeur Davide Beatrici, connu pour son travail sur Mumble, aurait utilisé des privilèges administratifs restants après un conflit interne pour supprimer une partie du travail GitHub et publier dans Cooker un paquet vide qui rendait obsolètes des paquets GNOME et COSMIC.

L'accusation est lourde; elle doit rester attribuée. OpenMandriva l'affirme. BleepingComputer a ensuite rapporté que Beatrici rejetait le mot "sabotage", tout en le citant disant qu'il avait supprimé les dépôts et paquets Cosmic et GNOME et poussé un paquet les rendant obsolètes. De l'extérieur, juger l'intention serait fragile. Pour les mainteneurs, le point pratique est ailleurs: l'infrastructure doit résister à la colère, au burnout, aux malentendus et aux conflits humains ordinaires.

Ce que l'on sait

OpenMandriva est une distribution Linux communautaire maintenue par l'OpenMandriva Association. BleepingComputer rappelle qu'elle est issue de Mandriva Linux en 2012 et qu'elle se distingue par l'usage de LLVM/Clang pour construire une grande partie du système.

Selon le message officiel, Beatrici a rejoint le projet et proposé de migrer ou de miroiter l'infrastructure de dépôts vers son instance privée OneDev. Une partie de l'équipe préférait conserver une infrastructure publique comme GitHub plutôt que placer des dépôts importants entre les mains privées d'une seule personne.

Après le conflit, OpenMandriva dit qu'une partie du travail GitHub a été supprimée et qu'un paquet vide dans Cooker a rendu obsolètes des paquets GNOME et COSMIC. Cooker est la branche rolling de développement, pas la branche stable, mais c'est tout de même un canal de paquets utilisé.

Le projet a dit restaurer les dépôts et les paquets, et avoir mené un audit complet qui n'a trouvé aucun autre problème en dehors des paquets supprimés. Linuxiac et LWN ont repris les points principaux; BleepingComputer a ajouté la réponse attribuée à Beatrici.

Pourquoi c'est important

Le risque supply chain est souvent associé à npm, au typosquatting, aux tokens CI volés ou à xz Utils. Ici, le risque est plus ordinaire: l'accès mainteneur.

Qui peut supprimer un dépôt? Qui peut publier un paquet qui retire tout un environnement de bureau? Qui garde des droits admin après une tâche temporaire? Sur Hacker News, la discussion a vite porté sur ces sujets: RBAC, privilèges temporaires, backups et capacité des petites distributions à appliquer des contrôles sérieux.

Une petite communauté n'a pas forcément une équipe sécurité d'entreprise. Mais une distribution publie des paquets qui arrivent sur les machines des utilisateurs. Cela change la responsabilité.

Le problème des accès

Les projets open source donnent souvent des droits larges parce que quelqu'un accepte un travail ingrat: migration de dépôts, mirrors, CI, packaging, builds. Puis l'accès temporaire devient permanent. Personne ne met d'expiration. Personne ne se souvient des tokens encore actifs.

Un bon contrôle d'accès n'est pas un manque de confiance. Il rend la confiance supportable quand une relation casse. Il protège aussi les contributeurs honnêtes, car il limite le rayon d'action et conserve une trace vérifiable.

Checklist mainteneurs

Appliquer le moindre privilège. Donner l'accès nécessaire à la tâche, pas tout ce qui pourrait être pratique un jour.

Mettre une date de fin aux accès temporaires.

Demander deux personnes pour les opérations destructrices: suppression de dépôts, paquets obsolètes, clés de signature, canaux de release, secrets CI.

Protéger le pipeline de paquets, pas seulement Git. Une branch protection propre ne sert pas si un compte peut publier un paquet dangereux.

Garder des sauvegardes hors de la plateforme administrée et tester les restaurations.

Séparer les rôles: merge, publication de paquets, clés de signature, DNS, hébergement, mirrors et administration de chat ne doivent pas dépendre d'un seul compte.

Écrire l'offboarding: équipes GitHub, permissions de paquets, tokens CI, deploy keys, registries et mirrors.

Pour utilisateurs et entreprises

La leçon n'est pas d'éviter les petits projets. Il faut regarder comment ils gouvernent le risque: incidents publiés rapidement, séparation stable/développement, restauration expliquée, releases signées, possibilité de pinner ou de mirrorer les dépendances critiques.

Les étoiles GitHub et la cadence de release ne suffisent pas. Le risque dépend aussi de la gouvernance, du bus factor et du contrôle du pipeline.

Conclusion

L'open source a besoin de confiance. Il a aussi besoin de systèmes qui continuent à fonctionner quand la confiance casse.

Après OpenMandriva, l'action utile est ennuyeuse: lister admins, publicateurs de paquets, clés de signature, backups et secrets CI. Puis retirer tout droit qui existe seulement parce que personne n'a fait le ménage.