El incidente de OpenMandriva no vale solo como drama de una distribución Linux. La lectura útil es más aburrida y más importante: el open source funciona con confianza, pero los usuarios instalan el resultado como infraestructura.

Pipeline de paquetes open source con llaves de acceso auditoría y copia de seguridad

El 8 de julio OpenMandriva publicó un comunicado en su foro sobre varias interrupciones y lo llamó un intento de sabotaje de la distribución. Según el proyecto, el excolaborador Davide Beatrici, conocido por su trabajo en Mumble, usó privilegios administrativos que aún conservaba tras un conflicto interno para borrar parte del trabajo en GitHub y publicar en Cooker un paquete vacío que obsoletaba paquetes de GNOME y COSMIC.

La acusación es grave, así que conviene atribuirla con cuidado. OpenMandriva hace esa acusación. BleepingComputer informó después que Beatrici rechazó la palabra "sabotage", aunque lo citó diciendo que borró repositorios y paquetes de Cosmic y GNOME y subió un paquete que los obsoletaba. Desde fuera no tiene sentido juzgar el motivo. Para los mantenedores, el punto práctico es otro: la infraestructura debe resistir enfados, burnout, malentendidos y conflictos humanos normales.

Qué se sabe

OpenMandriva es una distribución Linux comunitaria mantenida por la OpenMandriva Association. BleepingComputer recuerda que nació como fork de Mandriva Linux en 2012 y que destaca por construir buena parte del sistema con LLVM/Clang en vez de GCC.

Según el post oficial, Beatrici se unió al proyecto y ofreció migrar o espejar la infraestructura de repositorios a una instancia privada de OneDev. Parte del equipo no estaba cómoda con poner repositorios importantes en manos privadas de una sola persona y prefería mantener GitHub como infraestructura pública.

Después de un conflicto interno, OpenMandriva dice que se borró parte de su trabajo en GitHub y que se publicó en Cooker un paquete vacío que obsoletaba GNOME y COSMIC. Cooker es la rama rolling de desarrollo, no la estable, pero sigue siendo un canal real de paquetes.

El proyecto dijo que estaba restaurando repositorios y funcionalidad de paquetes, y que una auditoría completa no encontró otros problemas fuera de los paquetes eliminados. Linuxiac y LWN recogieron los puntos principales; BleepingComputer añadió la respuesta atribuida a Beatrici.

Por qué importa

Hablamos mucho de supply chain risk como malware en npm, typosquatting, tokens CI robados o xz Utils. Este caso apunta a algo menos exótico: acceso normal de mantenedor.

¿Quién puede borrar repositorios? ¿Quién puede publicar un paquete que retire escritorios enteros? ¿Quién conserva permisos de admin cuando una tarea temporal termina? En Hacker News, la discusión se movió rápido hacia esas preguntas: RBAC, permisos temporales, backups y si una distro pequeña puede permitirse controles maduros.

La respuesta incómoda: una comunidad pequeña quizá no tenga un equipo de seguridad empresarial, pero una distribución publica paquetes que terminan en máquinas de usuarios. Eso cambia el listón.

El problema de acceso

Muchos proyectos dan permisos amplios porque alguien se ofrece para trabajo ingrato: migrar repositorios, mantener mirrors, arreglar CI, empaquetar, cuidar builds. Luego el acceso temporal se queda. Nadie pone fecha de caducidad. Nadie recuerda qué tokens o permisos siguen vivos.

El buen control de acceso no es falta de confianza. Hace que la confianza sea soportable cuando una relación se rompe. También protege a los colaboradores honestos: limita el daño y deja un rastro auditable.

Checklist para mantenedores

Aplicar least privilege. Dar acceso para la tarea actual, no para todo lo que quizá ocurra algún día.

Poner caducidad a permisos temporales. Si alguien necesita admin para una migración, decidir desde el principio cuándo termina.

Exigir revisión de dos personas para acciones destructivas: borrar repositorios, obsoletear paquetes, cambiar llaves de firma, tocar canales de release o rotar secretos CI.

Proteger el pipeline de paquetes, no solo Git. Branch protection no ayuda si una cuenta puede publicar un paquete dañino.

Mantener backups fuera de la plataforma administrada y probar restauraciones.

Separar roles: merge de código, publicación de paquetes, llaves de firma, DNS, hosting, mirrors y administración de chats no deben concentrarse en una sola cuenta.

Hacer offboarding con checklist: equipos de GitHub, permisos de paquetes, tokens CI, deploy keys, credenciales de registry y acceso a mirrors.

Para usuarios y empresas

La lección no es evitar proyectos pequeños. La pregunta mejor es cómo gobiernan el riesgo: ¿publican incidentes rápido? ¿separan rama estable de desarrollo? ¿explican recuperación? ¿firman releases? ¿puedes fijar versiones o usar mirrors internos?

Las estrellas y la cadencia de releases no bastan. El riesgo de dependencias también incluye gobernanza, bus factor y control del pipeline de paquetes.

Conclusión

Open source necesita confianza. También necesita sistemas que sigan funcionando cuando la confianza se rompe.

Después de OpenMandriva, lo útil es revisar lo aburrido: admins, publicadores de paquetes, llaves de firma, backups y secretos CI. Quita todo permiso que siga ahí solo porque nadie lo limpió.