El futuro de Flatpak

• Flatpak actualmente goza de popularidad entre desarrolladores y usuarios, pero han surgido problemas de estancamiento en el desarrollo del proyecto en sí
• La salida de desarrolladores clave y los cuellos de botella han provocado retrasos en la incorporación de nuevas funciones y en la revisión de código
• Se han propuesto diversas mejoras como soporte para imágenes OCI, granularidad de permisos y control de acceso al audio, pero su integración real ha avanzado con lentitud
• Para el desarrollo a largo plazo del proyecto, se debate la adopción del estándar de tecnología de contenedores (OCI) y una reimplementación basada en Rust
• Resolver desafíos clave como la mejora de los portales, el soporte de drivers y el sandboxing de red será decisivo para el crecimiento de Flatpak

---

Resumen y estado actual del proyecto Flatpak

• Flatpak comenzó en 2007 como un proyecto similar, tuvo su primer lanzamiento en 2015 como XDG-App y en 2016 cambió su nombre a Flatpak
• Proporciona herramientas de línea de comandos, herramientas de compilación y componentes de runtime, y presenta características de aislamiento de aplicaciones (sandboxing) mediante cgroups, namespaces, bind mount, seccomp y Bubblewrap
• Usa OSTree como mecanismo de distribución predeterminado y, más recientemente, también incorporó soporte para imágenes OCI, utilizado en Fedora y otros entornos
• Aunque ha tenido éxito con el crecimiento de la tienda de apps Flathub y la adopción por parte de distribuciones, internamente el proyecto atraviesa una desaceleración del desarrollo activo

Estancamiento del desarrollo y causas principales

• Existe actividad de mantenimiento y parches de seguridad, pero el desarrollo de nuevas funciones de gran escala y la revisión de código han quedado estancados durante largos periodos
• La salida de desarrolladores principales (como Larsson) ha dejado pocos revisores, creando un entorno donde es difícil incorporar nuevos contribuidores o cambios grandes
• Incluso funciones como la de preinstalación de Flatpak (Preinstall), impulsada por contribuciones de Red Hat y otros, han sufrido repetidamente demoras de meses hasta su integración final debido a revisiones lentas y a la salida de responsables

OSTree y soporte para imágenes OCI

• OSTree se aplicó con éxito en Flatpak, pero por problemas de herramientas no estándar o limitadas, no ha tenido un desarrollo activo más allá del mantenimiento
• OCI cuenta con un amplio ecosistema de herramientas para imágenes de contenedores, por lo que el equipo de Flatpak espera que su adopción reduzca la carga de mantenimiento y el esfuerzo duplicado
• También se han propuesto en nuevos PR compatibilidades como el formato de compresión eficiente zstd:chunked, pero siguen en estado de retraso o sin integración

Gestión de permisos y granularidad del sandbox

• Flatpak se centra en restringir el acceso al sistema mediante sandboxing, y las versiones recientes ya admiten permisos más granulares (por ejemplo, --device=input)
• Como las distribuciones Linux incluyen distintas versiones de Flatpak, surgen problemas de compatibilidad de versiones y de adopción limitada de nuevas funciones de permisos
• En el caso de los permisos de audio, las limitaciones de PulseAudio dificultan separar reproducción y grabación, por lo que se plantea la necesidad de mejorar esto con PipeWire y tecnologías similares
• La compatibilidad insuficiente con sandboxing anidado impide que aplicaciones como los navegadores web usen internamente sandboxes adicionales

D-Bus y sandboxing de red

• Flatpak no accede directamente a D-Bus, sino que usa xdg-dbus-proxy para un modelo de comunicación filtrada
• Wick ha expresado la intención de mover las políticas de filtrado al broker de D-Bus para permitir la aplicación dinámica de políticas y un control de acceso basado en cgroups
• Debido a la implementación incompleta de network namespaces, existe la posibilidad de comunicación no intencional entre apps Flatpak cuando se exponen puertos de localhost (caso real: AusweisApp)
• Los drivers de NVIDIA se distribuyen por separado para cada runtime, lo que genera tráfico de red excesivo y dificultades de actualización. Tomando como referencia el modelo de Valve, se exploran alternativas como compartirlos desde el host o usar compilación estática

Uso de portales y necesidad de mejoras

• Los portales son APIs basadas en D-Bus para acceder a recursos externos, y cubren funciones como archivos, impresión y URLs
• Portales como Documents funcionan bien a nivel de archivo individual, pero en apps de uso intensivo como GIMP o Blender, un modelo de permisos demasiado granular se vuelve una limitación
• Junto con propuestas de nuevas APIs como autocompletado de contraseñas, llaves FIDO y síntesis de voz, también se discuten ideas para reducir la dificultad de desarrollo y una reimplementación en Rust

El futuro de Flatpak (Flatpak-next)

• Partiendo del supuesto de un escenario donde Flatpak ya no continúe desarrollándose, se discute a largo plazo una gran transición hacia el ecosistema OCI (imágenes, registros, herramientas, políticas y más)
• Se espera que una reimplementación en Rust y la unificación con el ecosistema de contenedores ofrezcan ventajas en carga de gestión, mantenimiento y escalabilidad

Resumen de preguntas y respuestas

• Ante la pregunta de cómo se manejarían las apps Flatpak existentes en una transición a OCI, se respondió que no habría grandes problemas gracias a la automatización de compilaciones en Flathub
• Sobre el problema de la falta de metadatos en los registros OCI, se indicó que ya se están definiendo estándares para datos no relacionados con imágenes, aunque aún hace falta desarrollo e integración para aplicarlos realmente
• Respecto a los planes de soporte directo para PipeWire, se explicó que las discusiones técnicas siguen en curso y que la dirección apunta a una integración basada en políticas de PipeWire

Conclusión

• Flatpak ya se consolidó como una plataforma estándar de distribución y sandboxing, pero aún enfrenta múltiples retos de mejora, como el estancamiento en revisiones y nuevo desarrollo, problemas de permisos/red/drivers y la transición a estándares futuros
• El uso de tecnología de contenedores basada en OCI y de Rust podría convertirse en un nuevo motor para la evolución de Flatpak
• Los puntos principales pueden resumirse en asegurar revisores, estandarización, expansión del ecosistema y mejora de la experiencia de usuario

[ndrgrd]

Creo que sería mejor no bloquear por completo los permisos de acceso, sino mostrar claramente a qué directorio se está accediendo.

Android está bastante bien en ese aspecto, pero ahí agrupan demasiado los permisos y terminas teniendo que permitir también permisos de un nivel que no necesitas...

[GN⁺]

Comentarios en Hacker News

• Comparte el punto destacado en la presentación de Wick: el proyecto Flatpak parece funcionar bien por fuera, pero en la práctica no está recibiendo desarrollo activo; el mantenimiento de seguridad y el mantenimiento básico continúan, pero casi no se agregan funciones nuevas. Considera problemático que, aunque se suban muchas propuestas de funciones nuevas (Merge Requests), no haya quien las revise y todo quede estancado. En especial, cree que el papel de Red Hat se volvió aún más importante después de que en RHEL 10 dejara de ofrecer paquetes de escritorio y recomendara instalar paquetes desde Flathub. Si Red Hat realmente quiere convertirlo en una alternativa adecuada, espera que invierta más recursos. También coincide con la observación de Wick de que el soporte de nuevos permisos cambia según la versión de Flatpak y por eso se necesita backwards compatibility. Él mismo, al distribuir juegos en Flathub, experimentó directamente problemas con permisos de audio y controles, la falta de soporte para --device=input y la imposibilidad actual de configurar permisos granulares, como permitir solo los parlantes y bloquear el micrófono
  • Menciona el caso de Red Hat, que al principio iba a distribuir Firefox y Thunderbird en RHEL 10 solo como Flatpak, pero en la práctica también ofreció paquetes rpm después del lanzamiento GA. Influyeron varias razones combinadas, como la falta de soporte para Native Messaging, la imposibilidad de desplegar políticas centralizadas y problemas de integración con el escritorio
• Comparte que, cuando Flatpak recién comenzaba, conoció directamente a su desarrollador original y discutió con él la filosofía de diseño. Intentó convencerlo de que era un problema que en Flatpak los permisos quedaran atados al nombre del paquete y que no existiera aislamiento por instancia. Es decir, no se puede ejecutar la misma app Flatpak en varias instancias separadas con permisos distintos para cada una, por ejemplo permitiendo solo ciertos subdirectorios dentro de Documents. Cree que esa misma estructura en MS, Apple App Store y macOS también está mal diseñada, y que todo el mundo lo está haciendo mal. Por ejemplo, aunque ocurra un RCE (ejecución remota de código) en un documento de LibreOffice, el acceso a sus otros documentos debería quedar bloqueado, y sostiene que aunque el proveedor no se preocupe por la seguridad, el sandbox de Flatpak debería brindarla
  • Presenta una visión crítica frente al aumento de complejidad con fines de seguridad. Como la PC es suya, considera innecesarios los permisos por instancia, el sandbox y las restricciones de compartición de archivos, y quiere mantener la idea tradicional de que “todo es un archivo”. Como ejemplo, se queja del entorno sandbox donde Thunderbird y Firefox no pueden acceder al directorio /tmp, lo que vuelve muy incómodo guardar adjuntos o abrirlos desde otras apps. Afirma que el dueño de la computadora debe ser el usuario, no el desarrollador, y piensa que este exceso de seguridad reduce la productividad. Lo compara con una Useless Machine
  • Plantea que es posible que el equipo de desarrollo de Flatpak también entendiera este problema. Desde una visión pragmática, si Flatpak hubiera elegido un modelo técnicamente perfecto, la barrera de entrada para los desarrolladores de apps, especialmente los multiplataforma, habría sido demasiado alta y Flatpak no se habría expandido
  • Propone que un modelo de permisos por instancia es muy atractivo, pero que para configuraciones del entorno (git config, carpeta de fuentes, etc.) sería práctico un enfoque híbrido con una opción para que todas las instancias tengan el mismo permiso de acceso
  • Piensa que lo deseable sería rediseñar todo el sistema operativo para dar capacidades separadas a cada instancia en ejecución y soportar varias funciones como cuotas de disco, logging, proxies y separación fina de permisos. Sostiene que no es un problema exclusivo de Flatpak
  • Para power users y usuarios sensibles a la seguridad que necesitan un aislamiento estricto, como el sandboxing basado en hipervisor al estilo QubesOS, la separación por instancia es positiva. Pero para la mayoría de los trabajos de aislamiento, el enfoque intuitivo es que ocurra dentro de la propia app. Igual que en el sandboxing de navegadores web, lo ideal sería que Flatpak soportara nested sandbox, pero por ahora no lo hace. También existen problemas bastante complejos, como la integración entre firma de código y sandbox, o los namespaces de UID
• Como usuario veterano y entusiasta de Flatpak, cuenta que fue innovador y permitió usar fácilmente apps modernas en todas las distribuciones Linux, pero como no ha cambiado en varios años, fue perdiendo interés poco a poco. Ahora cubre casi todo con AUR y le da pena ver el estancamiento de Flatpak
  • Como usuario, fuera de la facilidad de uso, no tuvo una experiencia particularmente buena con Flatpak. Menciona varios problemas de integración con temas, cursor, selector de archivos, permisos y Drag&Drop, además de la necesidad de herramientas adicionales para usar ciertas funciones. Piensa que, si la UX es mala, beneficios de seguridad como el sandboxing pierden sentido, y sostiene que si Linux no tuviera problemas de portabilidad binaria, Flatpak no haría falta
  • Cuenta que la combinación Fedora+GNOME+Flatpak en algún momento le pareció muy innovadora, pero recientemente volvió a Arch. Los repositorios de Arch se enriquecieron mucho y casi ya no necesita usar AUR
  • Le pregunta a alguien con experiencia administrando varios paquetes cómo fue su experiencia con makedeb, y menciona que makedeb está basado en PKGBUILD, por lo que tiene gran portabilidad, y le sorprende que no sea más conocido
• No está 100% de acuerdo con la postura de Drew DeVault de que “las distribuciones deberían encargarse del empaquetado de apps”, pero presenta un texto de debate de larga data y un enlace de referencia. Desde esa mirada, el modelo correcto es que la comunidad (la distribución), representando a los usuarios, administre los paquetes. Sostiene que el modelo de empaquetar fuera de la distribución, como Flatpak/Snap/AppImage, no es bueno en lo fundamental
  • En respuesta, alguien rebate que el desarrollador que crea directamente la app es quien mejor se adapta a gestionar el empaquetado. En especial, en el software de código cerrado, los derechos legales de distribución y empaquetado suelen estar monopolizados, y aun en open source, considera que la intervención arbitraria en el empaquetado por parte de alguien ajeno al equipo principal solo provoca bugs innecesarios, retrasos en los lanzamientos y nuevos problemas. Quiere actualizaciones rápidas y al día, y software original sin alteraciones de empaquetado. Considera que el problema es que Flatpak intenta hacer demasiadas cosas, y también desconfía del propio modelo de app store. Afirma que en Windows y macOS se puede distribuir binarios libremente sin app store, y que la seguridad mínima la da el sistema operativo a nivel de firma de código, por lo que no hace falta que un sistema de empaquetado de terceros lleve la batuta
  • Sostiene que los desarrolladores de apps deberían poder distribuir directamente, poniendo como ejemplo la experiencia simple de instalación en Windows. Cree que es difícil que los mantenedores tengan la escala necesaria para soportar todas las distribuciones, y que eso es un obstáculo para el avance del escritorio Linux
  • Señala que el esfuerzo de tener que empaquetar por separado para múltiples distribuciones termina restándole sentido
  • Opina que es poco realista que las distribuciones empaqueten todo el software del mundo
  • Desde la postura de que las distribuciones empaquetan mal las apps, dice que le alegra ver una mayor adopción de Flatpak y que los desarrolladores deberían poder distribuir fácilmente sus apps sin intermediarios
• Coincide con la crítica de que Flatpak siga usando PulseAudio y vaya retrasado en la adopción de PipeWire. Como PulseAudio unifica los permisos de parlantes y micrófono y no permite separarlos, si a una app se le da permiso de salida de audio automáticamente parecería poder acceder también al micrófono, lo que constituye un gran agujero de seguridad
  • Dice que suele ver usuarios de Linux burlándose de los errores de diseño o la falta de libertad en Windows/macOS, pero que también hay que reconocer estos problemas de diseño fundamentales. Cree que el ecosistema Linux tiende a dejar estos problemas sin resolver porque no logra definir con claridad quién es responsable
• Instaló VSCode/Codium como Flatpak para depurar Python, pero por problemas de permisos y configuración tardó mucho en dejar listo el depurador. Al final, al instalar la versión Snap, todos los problemas se resolvieron
  • Piensa que Flatpak es adecuado para apps grandes de escritorio, por ejemplo Chrome o Chromium, pero no para herramientas del sistema
  • Cuenta que la versión Flatpak de Emacs solo le trajo ineficiencia y frustración
• Al cambiar a una immutable distro basada en Flatpak, dice que cuando encaja bien está muy bien, pero en la práctica sorprendentemente muchas cosas no funcionan y no cumple las expectativas. Por ejemplo, experimentó varias incomodidades con la ejecución de herramientas externas para Godot, múltiples ajustes de permisos, problemas de interoperabilidad entre Flatpaks (por ejemplo Firefox y KeepassDX), crashes en los Flatpaks de Godot y Krita, y entornos heterogéneos con AppImage/.rpm no Flatpak, entre otros. Menciona que le gustaría ver mucha más innovación en Flatpak
• Flatpak tiene una estructura que hace imposible empaquetar apps que crean interfaces de red virtuales como Tailscale. En macOS, en cambio, mediante APIs se pueden granular los permisos de red y por eso Tailscale puede distribuirse como app sandboxed en la Mac App Store
  • Gracias a esa API, es posible la distribución de la app sandboxed de Tailscale para macOS. En cambio, en distribuciones Linux “atómicas” como Silverblue o Bluefin, que dependen de Flatpak, se vuelve difícil usar este tipo de software
  • Considera que Flatpak sí tiene sentido para apps grandes de escritorio como OBS Studio, pero para algo como Tailscale, que actúa como servicio del sistema, un paquete base de la distribución es más adecuado. En Arch Linux existe como paquete oficial
  • En Flatpak hay desvíos posibles como flatpak-spawn o polkit-exec, pero en ese caso prácticamente se renuncia a la protección del sandbox
  • Sospecha que el intento de resolver de una sola vez, en la parte más alta de Linux, tanto un sistema detallado de permisos como el empaquetado, es excesivamente complejo, y que el estancamiento de Flatpak o el agotamiento de sus desarrolladores podrían deberse a eso. Como en Linux moderno no existe un sistema de permisos fundamental, cree que antes que buscar una configuración de permisos perfecta, la prioridad real es resolver la distribución de software, el empaquetado y el sistema de actualizaciones
  • Opina que algo como Tailscale debería ir por sysext (extensión del sistema) y que Flatpak no es adecuado
• Respecto a las propuestas de distribuir por Flatpak, cuenta que al desarrollar la app KmCaster basada en Java le pidieron portarla a Flatpak, pero solo sintió una carga extra: dos métodos de instalación, gestión de estadísticas de descargas, confianza en repositorios de terceros, aumento del número de gestores de paquetes y duplicación de repositorios. En la práctica no vio ventajas reales
  • Aun así, menciona como aspectos positivos de Flatpak la comodidad de uso en immutable distros, la eliminación de la necesidad de gestionar versiones de Java, la visibilidad al aparecer en búsquedas de Flathub y las actualizaciones automáticas
• No es mantenedor ni desarrollador de open source, pero dice que no entiende por qué, si innumerables distribuciones Linux comparten el mismo problema de gestión de paquetes, no pueden unir fuerzas y concentrarse en complementar y universalizar Flatpak
  • Responden que es difícil unificarlo en una sola cosa porque cada distribución tiene una forma distinta de hacer distribución, y que la diversidad de opciones es una ventaja del ecosistema open source. Personalmente, prefiere los gestores de paquetes tradicionales del sistema
  • Dice que, siguiendo esa lógica, entonces solo debería existir GNOME, y que la diversidad de la comunidad y de la toma de decisiones es importante
  • Flatpak no le sirve absolutamente para nada, y no quiere que le exijan contribuir a software que él no usa