История OpenMandriva важна не как очередная драма в Linux-сообществе. Полезный вывод скучнее и серьёзнее: open source держится на доверии, но пользователи ставят результат как инфраструктуру. Когда конфликт внутри команды ломается, доступы к репозиториям, package publishing rights и backup suddenly stop being boring details.

Open source package pipeline with access keys audit trail and backup vault

8 июля OpenMandriva опубликовала forum statement о нескольких disruptions и назвала происходившее attempted distribution sabotage. По версии проекта, бывший участник Davide Beatrici, известный работой над Mumble, после внутреннего конфликта использовал оставшиеся administrative privileges, удалил часть GitHub repository work и опубликовал пустой package в Cooker, который obsoleted GNOME and COSMIC packages.

Формулировка тяжёлая, поэтому её нужно держать в attribution. Это allegation от OpenMandriva. BleepingComputer позже передал позицию Beatrici: он отверг слово "sabotage", но, по цитате из материала, признал удаление Cosmic and GNOME repositories/packages и публикацию package, который их obsolete'ил. Снаружи невозможно честно судить о мотиве. Но для maintainers важен не только мотив. Infrastructure must survive anger, burnout, misunderstandings and ordinary human conflict.

Что известно

OpenMandriva — independent community Linux distribution, maintained by the OpenMandriva Association. BleepingComputer reminds that it forked from Mandriva Linux in 2012 and is unusual because much of the system is built with LLVM/Clang rather than GCC.

According to official forum post, Beatrici joined the project and offered to migrate or mirror repository infrastructure to his private OneDev instance. Some team members did not want key repositories in one person's private hands and preferred public infrastructure such as GitHub. Then the post describes broader interpersonal conflict, resignations and a decision to sever at least some links to the private mirror.

OpenMandriva says the aftermath included deletion of part of its GitHub repository work and an empty package in Cooker that obsoleted GNOME and COSMIC packages. Cooker is the rolling development branch, not the stable track. But development branch is still a real package channel, and people can update from it.

The project said it was restoring deleted repositories and package functionality and had performed a full system audit, finding no other violations beyond removed packages. Linuxiac and LWN repeated the main claims. BleepingComputer added the reported response from Beatrici and said it had not heard back directly from him or the Mumble team by publication time.

Почему это не просто drama

Supply chain risk usually means npm malware, typosquatting, compromised CI tokens or xz Utils. This case points to a quieter risk: ordinary maintainer access. Who can delete a repo? Who can publish a package that removes desktop stacks? Who keeps admin rights after a temporary task ends?

Hacker News discussion quickly moved to these boring questions. People argued about admin access, temporary privileges, RBAC, volunteer capacity and whether small distros can be expected to run production-grade controls. The awkward answer is that small projects may not have enterprise security teams, but once they publish packages to users, their pipeline becomes part of users' machines.

The access problem

Open source projects often grant broad access because someone volunteers for thankless work: repository migration, mirrors, packaging, CI, build infrastructure. Then temporary access becomes permanent. Nobody schedules expiry. Nobody remembers which teams, tokens and package permissions still exist. A conflict happens, and the team discovers what one account can still do.

Good access control is not anti-trust. It makes trust survivable. It also protects honest contributors from suspicion because the system limits blast radius and keeps audit trail.

Why distributions are special

A broken library repo is painful. A Linux distribution repository can push changes into installed systems.

That is why the Cooker detail matters. An empty package that obsoletes GNOME and COSMIC packages is a package-management event, not just a GitHub event. Even if it affects development branch users, it is still a reminder that package publishing needs review, signing, backups and clear ownership.

Checklist for maintainers

Use least privilege. Give access needed for current work, not every possible future task.

Set expiry for temporary access. If someone needs broad rights for migration, decide in advance when those rights disappear.

Require two-person review for destructive operations: repository deletion, package obsoletes, signing-key changes, release-channel changes, CI secret rotation.

Protect package publishing separately from Git. Clean branch protection does not help if one account can publish a damaging package.

Keep backups outside the platform being administered. Test restores. A backup nobody has restored is only a comforting rumor.

Separate roles: code merge, package publishing, signing keys, DNS, hosting, mirrors and chat admin do not need to live in one account.

Make offboarding a checklist. Remove GitHub teams, package permissions, CI tokens, deploy keys, registry credentials and mirror access when someone leaves, especially after conflict.

Keep logs that outlive personal accounts and private infrastructure.

Checklist for users and companies

Do not read this as "avoid small open source projects." That would be lazy. Small projects make useful software.

Better questions: does the project publish incidents quickly? Does it separate stable users from development branch risk? Does it explain recovery? Does it audit access? Are releases signed? Can you pin or mirror critical packages during an incident?

For companies, stars and release cadence are not enough. Dependency risk includes governance, bus factor and package pipeline control.

The takeaway

Open source needs trust. It also needs systems that continue working when trust breaks.

The constructive move after OpenMandriva is not gossip about one person. It is a boring review: list admins, package publishers, signing keys, backups and CI secrets. Then remove every permission that exists only because nobody cleaned it up.