OpenMandriva's Attempted Sabotage by Former Contributor

Un ancien contributeur d’Open Mandriva, David Beatatrice, a utilisé ses privilèges administratifs non révoqués pour supprimer des dépôts GitHub et publier des paquets vides, provoquant une crise au sein de la distribution, mais l’équipe a tout restauré sans perte de données.

Voir la source

SYNTHÈSE STRUCTURÉE

Contexte : une confiance mal placée

David Beatatrice, connu pour son travail sur Mumble, a rejoint Open Mandriva et a proposé de migrer l’infrastructure des dépôts GitHub vers son instance privée de Gitea. L’équipe, bien que méfiante (« nous ne voulions pas placer notre dépôt entre les mains privées d’une seule personne »), a accepté. Deux autres personnes l’ont rejoint, et des tensions interpersonnelles ont éclaté, avec des comportements jugés abusifs envers certains utilisateurs.

L’incident déclencheur : un bannissement de chat

Un des nouveaux contributeurs a été exclu du canal Matrix « cooker » (la branche de développement continu). En protestation, David et un autre contributeur ont quitté le projet. L’équipe a alors décidé de couper les liens avec l’infrastructure privée de David, ce qui l’a « tellement irrité qu’abusant des privilèges administratifs qu’il possédait encore, il a saboté la distribution ».

Les actions de sabotage : suppression de dépôts et paquets vides

David a supprimé des dépôts GitHub contenant des années de travail, et a publié un paquet vide dans le dépôt « cooker » qui rendait obsolètes tous les paquets GNOME et Cosmic. Cela aurait pu « endommager les systèmes des personnes utilisant GNOME ou Cosmic ». L’équipe a précisé que ces actions constituaient une infraction pénale, mais a choisi de ne pas poursuivre en justice.

La défense de David : une décision « planifiée » et non malveillante

David affirme que ce n’était « en aucun cas un sabotage ». Il explique avoir supprimé les dépôts GNOME et Cosmic car « Open Mandriva a toujours mis l’accent sur KDE et LXQt », et que l’équipe partageait cette philosophie, sauf quelques membres. Il ajoute qu’un autre contributeur avait supprimé certains de ses fichiers sans le prévenir, ce qui l’a poussé à agir : « Je l’ai pris personnellement parce que ce n’est pas cool ».

La réaction de l’équipe : restauration complète

Bernard, le chef du projet, a confirmé que « tout a été récupéré, aucune donnée perdue, pas même l’historique des commits ». Les paquets supprimés ont été restaurés et resteront jusqu’à ce qu’un consensus soit trouvé sur leur suppression. L’équipe a également effectué un audit complet du système et n’a trouvé aucune autre violation.

Leçons : une gestion de crise réussie

Malgré la gravité de l’incident, le projet a su se ressouder. Certains contributeurs partis à cause des tensions sont revenus après le départ des personnes accusées d’abus. L’intervenant note que « c’est toujours dommage de voir les choses ne pas fonctionner entre les gens, mais il est vraiment acceptable de se séparer ».

Un avertissement sur les privilèges non révoqués

Le cas illustre le danger de laisser des privilèges administratifs à un ancien contributeur. L’intervenant souligne que « ce n’est pas cool, ce n’est pas acceptable » de supprimer des données en partant, et que cela ressemble à une vengeance personnelle.

CONCEPTS CLÉS

  • Cooker : branche de développement continu d’Open Mandriva, où les paquets sont testés avant d’être intégrés à la version stable.
  • Gitea : forge logicielle légère auto-hébergée, alternative à GitHub.
  • Paquet vide : paquet RPM ou DEB qui ne contient aucun fichier, mais peut être utilisé pour marquer d’autres paquets comme obsolètes (via Obsoletes).
  • Privilèges administratifs : droits permettant de modifier, supprimer ou publier des ressources sur un dépôt ou un serveur.

CONCLUSION

Cet incident montre que la sécurité d’un projet open source repose autant sur la gestion des accès que sur la qualité du code. Le fait de ne pas révoquer rapidement les privilèges d’un contributeur mécontent peut entraîner des dégâts considérables, même si la restauration est possible. Comme le dit l’intervenant, « c’était une décision stupide », mais l’équipe a prouvé sa résilience en récupérant toutes les données et en apaisant les tensions. La leçon à retenir : révoquez les accès dès qu’un contributeur quitte le projet, et documentez clairement les procédures de décision pour éviter les actions unilatérales.

Du même canal

Tout voir