Fedora retira paquetes de Deepin por fallas de seguridad y abandono de mantenimiento

Introducción

En mayo de 2025, el Engineering Steering Committee (FESCo) de Fedora votó por unanimidad (7-0-0) la remoción definitiva de todos los paquetes relacionados con Deepin Desktop Environment (DeepinDE) de sus repositorios oficiales. La decisión no fue improvisada: respondió a un patrón de abandono prolongado, fallas de seguridad no resueltas y la incapacidad del proyecto para cumplir con los estándares mínimos de mantenimiento. Este caso sirve como case study sobre cómo la falta de gobernanza técnica en proyectos de software libre puede derivar en riesgos operativos para distribuciones enteras.

El episodio comenzó cuando el equipo de seguridad de openSUSE publicó un informe detallado sobre vulnerabilidades críticas en paquetes de Deepin, incluyendo problemas en el gestor de archivos (deepin-file-manager), el uso de Polkit obsoleto en deepin-api y deepin-system-monitor, y fallas en la interfaz D-Bus que permitían escalada de privilegios. Fedora, que incluía estos paquetes sin revisión de seguridad activa, descubrió que sus propios procesos de gobernanza eran insuficientes: las pautas para revisores habían sido eliminadas años atrás y no existían herramientas automatizadas para detectar problemas como los reportados por openSUSE.

Qué ocurrió

La gota que rebalsó: el informe de openSUSE

El 15 de mayo de 2025, el equipo de seguridad de openSUSE publicó un informe técnico que detallaba fallas críticas en tres componentes clave de Deepin:

1. deepin-file-manager: Problemas en la interfaz D-Bus que permitían race conditions y posible escalada de privilegios. Aunque se aplicaron parches parciales, algunos vectores de ataque persistieron.
2. deepin-api y deepin-system-monitor: Uso de Polkit 0.105 (versión obsoleta) con configuraciones inseguras que exponían permisos elevados sin autenticación adecuada.
3. Fallas de compilación: Los paquetes no podían construirse en Fedora 42, 43 ni 44 debido a dependencias rotas o incompatibilidades con bibliotecas actualizadas (como libsystemd).

Adam Williamson, integrante del equipo de Quality Assurance (QA) de Fedora, abrió un ticket en el sistema de seguimiento de problemas preguntando:

> «Si openSUSE detectó estos problemas, ¿qué pasó con los paquetes en Fedora? ¿Hubo algún análisis de seguridad previo?»

La respuesta fue un silencio incómodo. Una revisión interna reveló que:

• Fedora había estado distribuyendo estos paquetes sin ningún proceso de revisión de seguridad activa desde hacía años.
• Las pautas para revisores («Security Review Guidelines») habían sido eliminadas del repositorio oficial de Fedora en 2021, dejando un vacío documentado pero no reemplazado.
• Los paquetes no contaban con maintainers activos: el equipo DeepinDE SIG había perdido a la mayoría de sus miembros clave, incluyendo al coordinador original, Zamir Sun, quien confirmó en un correo a FESCo que el proyecto estaba «en modo supervivencia».

El colapso operativo

Para mayo de 2025, los paquetes de Deepin en Fedora ya estaban en estado de abandono funcional:

• Fallas de construcción: Los paquetes fallaban en compilaciones automáticas para Fedora 42, 43 y 44.
• Retiro previo: El entorno de escritorio ya había sido removido de las spins oficiales de Fedora y del archivo fedora-comps meses antes por imposibilidad de mantenerlo.
• Mantenedor único: Solo Felix Wang (alias topazus) seguía interactuando con los paquetes, pero ignoraba bug reports, maintainer pings y correos directos. Cuando la política de Fedora desheredaba automáticamente paquetes por inactividad, Wang los reclamaba sin resolver los problemas.

FESCo envió un correo formal de advertencia el 5 de mayo de 2025, otorgando 4 semanas para responder. No hubo respuesta sustantiva. El 19 de mayo, se votó la remoción definitiva.

Impacto para DevOps, Infraestructura y Seguridad

Riesgos operativos para equipos de DevOps

1. Inconsistencia en entornos críticos:

– Ejemplo concreto: Un equipo de DevOps usando Fedora 42 en sus runners de GitLab CI podría haber sufrido fallas aleatorias en scripts que interactuaban con deepin-file-manager (ej.: operaciones de archivos en contenedores).

1. Brecha en gobernanza de dependencias:

– Dato clave: Según el informe de openSUSE, el uso de Polkit obsoleto en deepin-api exponía a sistemas a ataques como CVE-2021-4034 (PwnKit), con CVSS 7.8 (NVD).

1. Impacto en Kubernetes/EKS:

Lecciones para equipos de Seguridad (SRE)

1. Falta de revisión proactiva:

– Recomendación práctica: Implementar un sistema de scanning automático en pipelines de construcción (ej.: integrar Trivy o Grype en Fedora koji).

1. Gobernanza débil en proyectos comunitarios:

– Dato de contexto: Según el Linux Foundation Report 2024, el 37% de las vulnerabilidades en distribuciones Linux provienen de paquetes mantenidos por equipos pequeños o unipersonales.

1. Retos en entornos híbridos:

Detalles técnicos

Componentes afectados y versiones

1. Escalada de privilegios vía D-Bus:

     dbus-send --system --type=method_call --dest=com.deepin.filemanager \
       /com/deepin/filemanager com.deepin.filemanager.Manager.Execute \
       string:"malicious_script.sh"
     

Esto permitía ejecutar comandos con permisos de root si el usuario tenía acceso al bus de sistema.

1. Bypass de autenticación en Polkit:

     [Allow Any]
     Identity=unix-user:*
     Action=*
     ResultAny=yes
     

Esto permitía a cualquier usuario ejecutar acciones con permisos elevados sin autenticación.

1. Fallas de compilación críticas:

     error: Failed build dependencies:
       systemd-devel >= 250 is needed by deepin-desktop-base-2024.05.1-1.x86_64
     

Esto impedía reconstruir imágenes de Fedora con DeepinDE, afectando a spins oficiales como Fedora KDE.

Qué deberían hacer los administradores y equipos técnicos

Pasos inmediatos para equipos de Fedora

1. Verificar y limpiar paquetes residuales:

   # Buscar paquetes huérfanos de Deepin
   dnf repoquery --unsolvable --orphaned --queryformat="%{name}" | grep deepin

   # Remover paquetes instalados manualmente
   sudo dnf remove deepin-\* libdeepin\*
   

1. Auditar dependencias en entornos de CI/CD:

     trivy fs --severity CRITICAL --format json . > deepin_audit.json
     

– Buscar especialmente deepin-api, deepin-file-manager y libdeepin.

1. Actualizar a Fedora 44 y limpiar caché:

   sudo dnf upgrade --refresh
   sudo dnf autoremove --purge-deepin
   

Recomendaciones para equipos de DevOps e Infraestructura

1. Implementar supply chain scanning en pipelines:

     # Ejemplo en GitHub Actions
     - name: Scan for deepin packages
       uses: anchore/scan-action@v3
       with:
         image: "fedora:44"
         severity: "critical"
     

1. Estandarizar entornos con SBOMs:

     syft packages fedora:44 -o spdx-json > fedora44_sbom.json
     

– Auditar SBOMs con herramientas como Dependency-Track.

1. Revisar políticas de mantenimiento:

– Revisión de actividad del mantenedor (ej.: commits en GitHub en últimos 6 meses).

– Uso de repology para verificar si el paquete está en otras distribuciones.

Acciones para equipos de Seguridad (SRE)

1. Auditar Polkit en sistemas Fedora:

   # Buscar configuraciones inseguras de Polkit
   grep -r "allow_any" /etc/polkit-1/rules.d/
   grep -r "unix-user:root" /etc/polkit-1/localauthority/
   

1. Implementar gVisor o Kata Containers:

     # Ejemplo de PodSecurityPolicy (deprecated, usar PodSecurity en Kubernetes 1.25+)
     apiVersion: policy/v1beta1
     kind: PodSecurityPolicy
     metadata:
       name: restricted
     spec:
       readOnlyRootFilesystem: true
       allowPrivilegeEscalation: false
     

1. Capacitar equipos en respuestas a incidentes:

     # playbook_remove_deepin.yml
     - hosts: all
       tasks:
         - name: Remove deepin packages
           dnf:
             name: "deepin-*"
             state: absent
             autoremove: yes
     

Conclusión

El retiro de DeepinDE de Fedora no fue un hecho aislado, sino el síntoma de problemas estructurales en la gobernanza de paquetes de terceros: falta de revisión de seguridad, abandono de mantenedores y ausencia de herramientas automatizadas. Este caso subraya la importancia de:

1. Automatizar la detección de vulnerabilidades en repositorios (ej.: integrar Trivy en Fedora koji).
2. Exigir estándares mínimos de mantenimiento para paquetes críticos (ej.: actividad reciente del mantenedor, uso de SBOMs).
3. Documentar y auditar procesos de remoción de paquetes problemáticos, especialmente en entornos híbridos (Fedora + Kubernetes).

Para equipos de DevOps e Infraestructura, la lección es clara: confiar no es un proceso. La remoción de Deepin en Fedora debe servir como recordatorio de que, en entornos de producción, la visibilidad y el control sobre las dependencias no son opcionales.

Fuentes

https://feed.itsfoss.com/link/24361/17344914/fedora-ditches-deepin