Incydent OpenMandrivy nie jest tylko dramą w projekcie linuksowym. Ważniejsza lekcja jest nudna: open source działa na zaufaniu, ale użytkownicy instalują jego wynik jak infrastrukturę.

Pipeline pakietów open source z kluczami dostępu audytem i backupem

8 lipca OpenMandriva opublikowała na forum statement o kilku zakłóceniach i nazwała sprawę próbą sabotażu dystrybucji. Według projektu były kontrybutor Davide Beatrici, znany z pracy przy Mumble, po konflikcie wewnętrznym użył pozostawionych uprawnień administracyjnych, usunął część pracy w GitHub i opublikował w Cooker pusty pakiet, który obsolete'ował pakiety GNOME i COSMIC.

To poważne oskarżenie, więc trzeba je tak opisywać: OpenMandriva tak twierdzi. BleepingComputer później podał, że Beatrici odrzucił słowo "sabotage", ale cytował go jako osobę mówiącą, że usunęła repozytoria i pakiety Cosmic oraz GNOME i wypchnęła pakiet, który je obsolete'ował. Z zewnątrz nie da się uczciwie ocenić motywu. Dla maintainerów ważne jest co innego: infrastruktura musi przetrwać złość, burnout, nieporozumienia i zwykłe konflikty między ludźmi.

Co wiadomo

OpenMandriva to społecznościowa dystrybucja Linuksa utrzymywana przez OpenMandriva Association. BleepingComputer przypomina, że powstała jako fork Mandriva Linux w 2012 roku i wyróżnia się użyciem LLVM/Clang zamiast GCC do budowy dużej części systemu.

Według oficjalnego posta Beatrici dołączył do projektu i zaproponował migrację lub mirror infrastruktury repozytoriów do prywatnej instancji OneDev. Część zespołu wolała publiczną infrastrukturę, taką jak GitHub, zamiast oddawania ważnych repozytoriów w prywatne ręce jednej osoby.

Po konflikcie, według OpenMandrivy, usunięto część pracy w GitHub i opublikowano w Cooker pusty pakiet obsolete'ujący GNOME i COSMIC. Cooker to rolling development branch, nie stable. Nadal jest to jednak prawdziwy kanał pakietów.

Projekt twierdzi, że przywracał repozytoria i pakiety oraz wykonał pełny audyt, który nie wykazał innych naruszeń poza usuniętymi pakietami. Linuxiac i LWN powtórzyły główne fakty, a BleepingComputer dodał opisywaną odpowiedź Beatriciego.

Dlaczego to ma znaczenie

Supply chain risk kojarzy się z malware w npm, typosquattingiem, skradzionymi tokenami CI albo xz Utils. Tu ryzyko jest bardziej zwyczajne: dostęp maintainera.

Kto może usunąć repozytorium? Kto może opublikować pakiet usuwający desktop stack? Kto zachowuje admin rights po tymczasowym zadaniu? Dyskusja na Hacker News szybko poszła właśnie tam: RBAC, tymczasowe uprawnienia, backupy i pytanie, czy małe dystrybucje stać na dojrzałe kontrole.

Niewygodna odpowiedź: małe projekty nie mają enterprise security team. Ale dystrybucja publikuje pakiety na komputery użytkowników. To zmienia odpowiedzialność.

Problem dostępu

Projekty open source często dają szerokie uprawnienia, bo ktoś zgłasza się do niewdzięcznej pracy: migracji repozytoriów, mirrorów, CI, pakietów, buildów. Tymczasowy dostęp zostaje. Nikt nie ustawia daty wygaśnięcia. Nikt nie pamięta starych tokenów.

Dobry access control nie oznacza braku zaufania. Sprawia, że zaufanie jest odporne, gdy relacja pęka. Chroni też uczciwych kontrybutorów, bo ogranicza zasięg szkód i zostawia audit trail.

Checklist dla maintainerów

Least privilege: daj dostęp do bieżącego zadania, nie do wszystkiego.

Tymczasowe prawa muszą wygasać.

Dwie osoby przy destrukcyjnych akcjach: kasowanie repozytoriów, obsolete packages, signing keys, release channels, CI secrets.

Chroń pipeline pakietów, nie tylko Git. Branch protection nie pomoże, jeśli jedno konto może wypchnąć szkodliwy pakiet.

Trzymaj backupy poza platformą, którą administrujesz, i testuj restore.

Oddziel role: merge, publikacja pakietów, signing keys, DNS, hosting, mirrors i chat admin nie powinny siedzieć w jednym koncie.

Offboarding rób checklistą: GitHub teams, package permissions, CI tokens, deploy keys, registry credentials, mirror access.

Dla użytkowników i firm

Wniosek nie brzmi: unikaj małych projektów. Lepsze pytania: czy projekt szybko publikuje incydenty, rozdziela stable i development, wyjaśnia recovery, podpisuje releases, pozwala pinować albo mirrorować krytyczne zależności?

Stars i release cadence nie wystarczą. Ryzyko zależności obejmuje governance, bus factor i kontrolę pipeline pakietów.

Wniosek

Open source potrzebuje zaufania. Potrzebuje też systemów, które działają dalej, gdy zaufanie pęka.

Po OpenMandrivie sensowny krok jest nudny: spisać adminów, package publishers, signing keys, backupy i CI secrets. Potem usunąć każde uprawnienie, które istnieje tylko dlatego, że nikt go nie posprzątał.