Der OpenMandriva-Vorfall ist mehr als Linux-Projektdrama. Die nützliche Lehre ist trockener und wichtiger: Open Source läuft auf Vertrauen, aber Nutzer installieren das Ergebnis als Infrastruktur.

Open-Source-Paketpipeline mit Zugriffsschlüsseln Audit-Protokoll und Backup-Tresor

Am 8. Juli veröffentlichte OpenMandriva im Forum eine Stellungnahme zu mehreren Störungen und sprach von einem versuchten Sabotageakt gegen die Distribution. Nach Darstellung des Projekts nutzte der frühere Contributor Davide Beatrici, bekannt durch Arbeit an Mumble, nach einem internen Konflikt verbliebene Administratorrechte, um Teile der GitHub-Arbeit zu löschen und in Cooker ein leeres Paket zu veröffentlichen, das GNOME- und COSMIC-Pakete obsolet machte.

Das ist eine schwere Behauptung und muss als solche stehen. OpenMandriva erhebt sie. BleepingComputer berichtete später, Beatrici weise das Wort "sabotage" zurück, zitierte ihn aber mit der Aussage, Cosmic- und GNOME-Repositories sowie Pakete gelöscht und ein obsoleting package veröffentlicht zu haben. Von außen lässt sich Motivation nicht sauber beurteilen. Für Maintainer zählt der Betriebspunkt: Infrastruktur muss Wut, Burnout, Missverständnisse und menschliche Konflikte überstehen.

Was bekannt ist

OpenMandriva ist eine Community-Linux-Distribution der OpenMandriva Association. BleepingComputer erinnert daran, dass sie 2012 aus Mandriva Linux hervorging und ungewöhnlich viel mit LLVM/Clang statt GCC baut.

Laut offiziellem Forenpost trat Beatrici dem Projekt bei und bot an, Repository-Infrastruktur auf seine private OneDev-Instanz zu migrieren oder zu spiegeln. Teile des Teams wollten zentrale Repositories lieber auf öffentlicher Infrastruktur wie GitHub halten.

Nach dem Konflikt, so OpenMandriva, wurden Teile der GitHub-Arbeit gelöscht und in Cooker ein leeres Paket veröffentlicht, das GNOME und COSMIC obsolet machte. Cooker ist der rolling development branch, nicht stable. Trotzdem ist es ein echter Paketkanal.

Das Projekt sagte, es stelle Repositories und Pakete wieder her und habe ein vollständiges Audit ohne weitere Verstöße durchgeführt. Linuxiac und LWN griffen die Kernaussagen auf; BleepingComputer ergänzte die berichtete Gegendarstellung.

Warum es wichtig ist

Supply-Chain-Risiko klingt oft nach npm-Malware, Typosquatting, gestohlenen CI-Tokens oder xz Utils. Dieser Fall zeigt eine banalere Gefahr: normale Maintainer-Rechte.

Wer kann ein Repository löschen? Wer kann ein Paket veröffentlichen, das Desktop-Stacks entfernt? Wer behält Adminrechte nach einer temporären Aufgabe? Auf Hacker News ging die Diskussion schnell zu genau diesen Fragen: RBAC, temporäre Privilegien, Backups und ob kleine Distributionen sich ernsthafte Kontrollen leisten können.

Die unbequeme Antwort: Kleine Projekte haben keine Enterprise-Security-Abteilung. Aber eine Distribution veröffentlicht Pakete auf Nutzersysteme. Das hebt die Verantwortung.

Das Zugriffsproblem

Open-Source-Projekte geben oft breite Rechte, weil jemand undankbare Arbeit übernimmt: Migrationen, Mirrors, CI, Packaging, Build-Infrastruktur. Temporärer Zugriff bleibt bestehen. Niemand setzt ein Ablaufdatum. Niemand erinnert sich an alte Tokens und Teams.

Gute Zugriffskontrolle ist kein Misstrauen. Sie macht Vertrauen belastbar, wenn eine Beziehung bricht. Sie schützt auch ehrliche Contributors, weil sie den Schaden begrenzt und ein Audit-Protokoll erhält.

Maintainer-Checkliste

Least privilege: Zugriff für die aktuelle Aufgabe, nicht für jede denkbare Zukunft.

Temporäre Rechte mit Ablaufdatum versehen.

Zwei-Personen-Review für destruktive Aktionen: Repositories löschen, Pakete obsolet machen, Signing Keys ändern, Release-Kanäle anfassen, CI-Secrets rotieren.

Die Paketpipeline schützen, nicht nur Git. Branch protection hilft wenig, wenn ein Konto gefährliche Pakete veröffentlichen kann.

Backups außerhalb der verwalteten Plattform halten und Wiederherstellung testen.

Rollen trennen: Code-Merge, Paketveröffentlichung, Signing Keys, DNS, Hosting, Mirrors und Chat-Admin gehören nicht in ein Konto.

Offboarding als Checkliste: GitHub-Teams, Paketberechtigungen, CI-Tokens, Deploy Keys, Registry-Zugänge und Mirrors.

Für Nutzer und Unternehmen

Die Lehre ist nicht, kleine Projekte zu meiden. Besser ist zu fragen: Werden Vorfälle schnell veröffentlicht? Trennt das Projekt stable von development? Erklärt es Recovery? Sind Releases signiert? Können kritische Abhängigkeiten gepinnt oder gespiegelt werden?

Stars und Release-Frequenz reichen nicht. Dependency Risk umfasst Governance, Bus Factor und Kontrolle der Paketpipeline.

Fazit

Open Source braucht Vertrauen. Es braucht auch Systeme, die weiter funktionieren, wenn Vertrauen bricht.

Nach OpenMandriva ist der nützliche Schritt langweilig: Admins, Paket-Publisher, Signing Keys, Backups und CI-Secrets auflisten. Dann alles entfernen, was nur noch existiert, weil niemand aufgeräumt hat.