O futuro do Flatpak

• Flatpak vem ganhando popularidade entre desenvolvedores e usuários, mas o problema de estagnação no desenvolvimento do próprio projeto está se tornando evidente
• Com a saída de desenvolvedores centrais e gargalos, a incorporação de novos recursos e as revisões de código estão sendo atrasadas
• Foram propostos vários recursos de fortalecimento, como suporte a imagens OCI, granularidade de permissões e controle de acesso a áudio, mas sua adoção real tem sido lenta
• Para o desenvolvimento de longo prazo do projeto, estão em discussão a adoção do padrão de tecnologia de contêineres (OCI) e uma reimplementação baseada em Rust
• Resolver desafios importantes, como melhorias nos portais, suporte a drivers e sandboxing de rede, será decisivo para o crescimento do Flatpak

---

Visão geral e estado atual do projeto Flatpak

• O Flatpak começou em 2007 como um projeto semelhante, teve seu primeiro lançamento em 2015 como XDG-App e, em 2016, passou a se chamar Flatpak
• Ele oferece ferramenta de linha de comando, ferramentas de build e componentes de runtime, com isolamento de aplicações (sandboxing) baseado em cgroups, namespaces, bind mount, seccomp, Bubblewrap e outros
• Usa OSTree como método padrão de distribuição e, mais recentemente, também passou a contar com suporte a imagens OCI, sendo utilizado em distribuições como o Fedora
• Apesar do crescimento da loja de aplicativos Flathub e da adoção por distribuições, internamente o projeto enfrenta uma desaceleração do desenvolvimento ativo

Estagnação do desenvolvimento e principais causas

• Há atividade de manutenção e correções de segurança, mas o desenvolvimento de grandes novos recursos e as revisões de código estão em longa estagnação
• Com a saída de desenvolvedores importantes (como Larsson), faltam revisores, o que dificulta a entrada de novos contribuidores e mudanças de grande porte
• Até recursos como a pré-instalação (Preinstall) do Flatpak, para os quais há contribuição de empresas como a Red Hat, têm repetido o padrão de levar meses até a integração final devido a atrasos na revisão e à saída de responsáveis

OSTree e suporte a imagens OCI

• O OSTree foi aplicado com sucesso ao Flatpak, mas, por problemas de ferramentas não padronizadas e limitadas, não tem recebido evolução ativa além da manutenção
• O OCI conta com um amplo ecossistema de ferramentas para imagens de contêiner, o que, do ponto de vista da equipe do Flatpak, pode reduzir a carga de manutenção e o esforço duplicado caso seja adotado
• Até recursos como suporte a formatos eficientes de compressão, como zstd:chunked, foram propostos em novos PRs, mas continuam em estado de atraso ou sem integração

Gerenciamento de permissões e granularidade do sandbox

• O Flatpak foca em restringir o acesso ao sistema por meio de sandboxing, e versões recentes do Flatpak oferecem granularidade de permissões (por exemplo, --device=input)
• Como as distribuições Linux usam versões diferentes do Flatpak, surgem problemas em que novos recursos de permissão não conseguem ser amplamente adotados, além de questões de compatibilidade entre versões
• No caso das permissões de áudio, as limitações de compatibilidade com o PulseAudio dificultam separar reprodução e gravação, e por isso se levanta a necessidade de melhorias com tecnologias como PipeWire
• O suporte insuficiente a sandboxing aninhado impede que aplicativos como navegadores usem internamente outros sandboxes

D-Bus e sandboxing de rede

• O Flatpak não acessa o D-Bus diretamente; ele usa o xdg-dbus-proxy para um modelo de comunicação filtrado
• Wick demonstrou a intenção de mover a política de filtragem para o broker do D-Bus, permitindo aplicação dinâmica de políticas e controle de acesso baseado em cgroup
• Devido à implementação insuficiente de namespaces de rede, existe a possibilidade de comunicação não intencional entre aplicativos Flatpak quando portas de localhost ficam expostas (caso real: AusweisApp)
• Os drivers da NVIDIA são fornecidos separadamente para cada runtime, o que causa tráfego de rede excessivo e dificuldade de atualização. Inspirando-se no modelo da Valve, estudam-se alternativas como compartilhamento com o host e compilação estática

Uso de portais e necessidade de melhorias

• Os portais são APIs baseadas em D-Bus para acesso a recursos externos, cobrindo várias funções como arquivos, impressão e URL
• Portais como o Documents funcionam bem no nível de arquivo, mas, para aplicativos com forte foco em usabilidade como GIMP e Blender, um modelo de permissões excessivamente granular se torna uma limitação
• Junto com propostas de novas APIs para autopreenchimento de senha, chaves FIDO e síntese de voz, também foram discutidas ideias para reduzir a dificuldade de desenvolvimento e até uma reimplementação em Rust

O futuro do Flatpak (Flatpak-next)

• Partindo da hipótese de que o Flatpak eventualmente deixe de ser desenvolvido, discute-se no longo prazo uma grande transição para o ecossistema OCI (com amplo uso de imagens, registries, ferramentas, políticas etc.)
• Uma reimplementação baseada em Rust e a unificação com o ecossistema de contêineres podem trazer vantagens em carga de gestão, manutenção e escalabilidade

Resumo de perguntas e respostas

• Sobre a questão de como lidar com os aplicativos Flatpak existentes em uma transição para OCI, a resposta foi que, com a automação de build do Flathub, isso não deve ser um grande problema
• Quanto ao problema da falta de metadados em registries OCI, há padrões para dados que não são imagens em desenvolvimento, mas será necessário trabalho de desenvolvimento e integração para adoção prática
• Sobre planos de suporte direto ao PipeWire, as discussões técnicas estão em andamento, e a direção apontada é uma integração baseada em políticas do PipeWire

Conclusão

• O Flatpak se consolidou como uma plataforma padrão de distribuição e sandboxing, mas ainda carrega vários desafios de melhoria, como estagnação em revisões e novo desenvolvimento, problemas de permissões/rede/drivers e transição para padrões futuros
• O uso de tecnologias de contêiner baseadas em OCI e Rust pode se tornar um novo motor de evolução para o Flatpak
• Os principais pontos podem ser resumidos como garantir revisores, padronização, expansão do ecossistema e melhoria da experiência do usuário

[ndrgrd]

Acho que, em vez de simplesmente bloquear o acesso, é melhor mostrar claramente a quais diretórios está sendo acessado.

O Android é razoável nesse aspecto, mas por outro lado agrupa as permissões de forma ampla demais, então acaba sendo preciso conceder junto permissões em um nível que nem é necessário...

[GN⁺]

Comentários do Hacker News

• Compartilha o destaque da apresentação de Wick de que o projeto Flatpak, à primeira vista, parece funcionar bem, mas na prática não tem desenvolvimento ativo, com manutenção de segurança e pequenas correções continuando, porém quase sem novas funcionalidades; considera problemático que muitas propostas de recursos (Merge Requests) sejam abertas e fiquem paradas por falta de revisão; especialmente agora que o RHEL 10 deixou de fornecer pacotes de desktop e recomenda instalar pacotes via Flathub, entende que o papel da Red Hat ficou ainda mais importante; se a Red Hat realmente quer transformar o Flatpak em um substituto adequado, gostaria que investisse mais recursos; concorda também com a observação de Wick de que, como o suporte a novas permissões varia conforme a versão do Flatpak, backward compatibility é necessária; ao distribuir um jogo no Flathub, vivenciou diretamente problemas com permissões de áudio e controles, falta de suporte a --device=input e a impossibilidade de definir permissões mais granulares, como liberar só o alto-falante e bloquear o microfone
  • Menciona o caso em que a Red Hat inicialmente pretendia distribuir Firefox e Thunderbird no RHEL 10 apenas como Flatpak, mas na prática também passou a fornecer pacotes rpm após o lançamento GA; vários motivos contribuíram para isso, como falta de suporte a Native Messaging, impossibilidade de distribuição centralizada de políticas e problemas de integração com o desktop
• Compartilha a experiência de quando o Flatpak começou, tendo conhecido pessoalmente o desenvolvedor original e discutido a filosofia de design; tentou convencer de que havia um problema estrutural no fato de as permissões ficarem atreladas ao nome do pacote e não haver separação por instância; ou seja, não é possível executar várias instâncias do mesmo app Flatpak com permissões diferentes para cada uma, como permitir apenas diretórios específicos dentro de Documents; considera que MS, Apple App Store e macOS sofrem do mesmo problema e que o mundo inteiro foi mal projetado nesse aspecto; por exemplo, mesmo que ocorra um RCE (execução remota de código) em um documento do LibreOffice, o acesso aos seus outros documentos deveria ser bloqueado; defende que o sandbox do Flatpak deveria fornecer segurança mesmo que o fornecedor do app não se preocupe com isso
  • Há uma visão crítica sobre esse aumento de complexidade em nome da segurança; como o PC é propriedade do usuário, permissões por instância, sandbox e restrições de compartilhamento de arquivos seriam desnecessárias, e prefere manter o conceito tradicional de que "tudo é arquivo"; cita como exemplo a frustração com ambientes sandbox em que Thunderbird e Firefox não conseguem acessar o diretório /tmp, tornando muito incômodo salvar anexos e abri-los em outros apps; argumenta que o dono do computador deve ser o usuário, não o desenvolvedor, e que esse excesso de segurança reduz a produtividade, comparando isso à Useless Machine
  • Levanta a possibilidade de que a equipe de desenvolvimento do Flatpak também entendesse esse problema; se o Flatpak tivesse adotado um modelo tecnicamente perfeito, isso talvez tivesse criado uma barreira de entrada grande demais para desenvolvedores de apps, especialmente os multiplataforma, e impedido a própria adoção do Flatpak
  • Sugere que um modelo de permissões por instância seria muito atraente, mas que, para configurações de ambiente como git config, pasta de fontes etc., uma abordagem híbrida com opção para todas as instâncias terem o mesmo acesso seria mais prática
  • Considera desejável redesenhar todo o sistema operacional para conceder capabilities separadas a cada instância em execução, com suporte a cota de disco, logging, proxy e separação fina de permissões; argumenta que não é apenas um problema do Flatpak
  • Para power users e usuários sensíveis à segurança, que precisam de isolamento rigoroso como sandboxing baseado em hipervisor no estilo QubesOS, a separação por instância é melhor; porém, para a maioria dos casos, o isolamento acontecer dentro do próprio app é a abordagem mais intuitiva; como no sandboxing de navegadores web, seria ideal que o Flatpak também suportasse nested sandbox, mas isso ainda não existe; há também problemas bem complexos envolvendo integração entre assinatura de código e sandbox, namespaces de UID etc.
• Como usuário entusiasta de longa data do Flatpak, relata que a tecnologia foi inovadora e facilitou usar apps atuais em qualquer distribuição Linux, mas que, por não ter mudado muito nos últimos anos, foi perdendo o interesse; hoje o AUR cobre quase tudo de que precisa e acha lamentável a estagnação do Flatpak
  • Como usuário, tirando o fato de ser fácil, não teve uma experiência particularmente boa com Flatpak; cita vários problemas de integração com tema, cursor, seletor de arquivos, permissões, Drag&Drop, além da necessidade de ferramentas extras para usar certos recursos; na sua visão, se o UX é ruim, os benefícios de segurança do sandboxing perdem valor; entende que, se não existisse o problema de portabilidade de binários no Linux, nem haveria necessidade de Flatpak
  • Relata que a combinação Fedora+GNOME+Flatpak pareceu muito inovadora por um tempo, mas recentemente voltou para Arch; os repositórios do Arch ficaram muito mais ricos e quase não há mais necessidade de usar AUR
  • Pergunta a alguém com experiência em manter vários pacotes sobre a experiência com makedeb; comenta que o makedeb é baseado em PKGBUILD, tem ótima portabilidade e estranha que não seja mais conhecido
• Não concorda 100% com a tese de Drew DeVault de que “as distribuições deveriam cuidar do empacotamento dos apps”, mas apresenta um texto antigo de discussão e um link de referência; há a visão de que o modelo em que a comunidade (a distribuição) gerencia os pacotes em nome dos usuários é o correto, e de que modelos como Flatpak/Snap/AppImage, em que o empacotamento é feito fora da distribuição, são fundamentalmente problemáticos
  • Em contraponto, argumenta-se que quem cria o app é quem está mais apto a cuidar do empacotamento; especialmente em software de código fechado, os direitos legais de distribuição e empacotamento são exclusivos; mesmo em open source, alguém fora da equipe principal interferindo arbitrariamente no empacotamento pode introduzir bugs desnecessários, atrasos de release e novos problemas; quer atualizações rápidas e sempre recentes, além de software original sem alterações de empacotamento; considera que o problema é o Flatpak querer fazer coisas demais e também tem ressalvas ao próprio modelo de app store; no Windows e no macOS é possível distribuir binários livremente sem app store, e a segurança mínima é fornecida no nível do sistema operacional por mecanismos como assinatura de código; um sistema de empacotamento de terceiros liderando isso seria desnecessário
  • Defende que os desenvolvedores de apps devem poder distribuir diretamente, usando como exemplo a experiência simples de instalação no Windows; considera que é difícil para mantenedores terem escala para suportar todas as distribuições, e que isso atrapalha o avanço do desktop Linux
  • Observa que a necessidade de empacotar separadamente para várias distribuições acaba reduzindo o sentido de tudo isso
  • Opina que é irrealista esperar que o mundo inteiro de software seja empacotado por distribuições
  • Partindo da ideia de que distribuições não fazem bem o empacotamento de apps, diz ficar feliz em ver a adoção do Flatpak crescer e acha que os desenvolvedores deveriam conseguir distribuir seus apps facilmente sem intermediários
• Concorda com a crítica de que o Flatpak continua dependente de PulseAudio e está atrasado na adoção do PipeWire; no PulseAudio, permissões de alto-falante e microfone ficam unificadas e não podem ser separadas, ou seja, ao conceder permissão de saída de áudio a um app, ele automaticamente pode acessar o microfone, o que seria uma grande brecha de segurança
  • Diz que vê muitos usuários Linux zombando dos erros de design e da falta de liberdade no Windows e no Mac, mas que também é preciso reconhecer esses problemas fundamentais de design; acredita que o ecossistema Linux tende a deixar problemas de lado sem definir claramente de quem é a responsabilidade
• Instalou VSCode/Codium via Flatpak para depuração em Python, mas gastou muito tempo configurando o debugger por causa de problemas de permissões e configuração; no fim, ao instalar a versão Snap, todos os problemas foram resolvidos
  • Acha que Flatpak é adequado para grandes apps de desktop, como Chrome e Chromium, mas não para ferramentas de sistema
  • Relata que a versão Flatpak do Emacs só trouxe ineficiência e frustração
• Ao migrar para uma immutable distro baseada em Flatpak, diz que funciona bem quando encaixa no caso de uso, mas que, na prática, mais coisas do que o esperado não funcionam, ficando abaixo das expectativas; cita problemas como execução de ferramentas externas no Godot, vários ajustes de permissões, interoperabilidade ruim entre Flatpaks como Firefox e KeepassDX, crashes no Flatpak do Godot e do Krita e convivência com ambientes heterogêneos como AppImage/.rpm fora do Flatpak; diz esperar mais inovação no Flatpak
• O Flatpak tem uma estrutura que não permite empacotar apps como o Tailscale, que criam interfaces de rede virtual; no macOS, é possível granularizar permissões de rede via API, o que permite distribuir o Tailscale como app sandboxed na Mac App Store
  • Graças a essa API, é possível a distribuição do app sandboxed do Tailscale para macOS; já em distribuições Linux “atomic” dependentes de Flatpak, como Silverblue e Bluefin, fica difícil usar esse tipo de software
  • Considera que o Flatpak faz sentido para grandes apps de desktop, como OBS Studio, mas que softwares como o Tailscale, que funcionam como serviços de sistema, combinam mais com pacotes nativos da distribuição; no Arch Linux, por exemplo, existe pacote oficial
  • Observa que há contornos possíveis no Flatpak com flatpak-spawn, polkit-exec etc., mas que, nesse caso, praticamente se abandona a proteção do sandbox
  • Suspeita que tentar resolver ao mesmo tempo um sistema refinado de permissões e empacotamento no topo do Linux seja complexo demais, e que a estagnação do Flatpak ou o esgotamento dos desenvolvedores possam vir disso; como o Linux moderno não tem uma estrutura fundamental de permissões, entende que, antes de buscar um sistema perfeito de permissões, as prioridades reais são distribuição de software, empacotamento e atualizações
  • Opina que algo como o Tailscale deveria ir para sysext, e que o Flatpak não é apropriado para isso
• Sobre propostas de distribuição via Flatpak, comenta que, ao desenvolver o app KmCaster baseado em Java, recebeu pedidos para portar para Flatpak, mas só sentiu mais carga de trabalho: dois métodos de instalação, gestão de estatísticas de download, confiança em repositórios de terceiros, aumento no número de gerenciadores de pacote e duplicação de repositórios; na prática, não viu vantagens reais
  • Ainda assim, cita pontos positivos do Flatpak, como facilidade de uso em immutable distros, eliminação da necessidade de gerenciar versões de Java, visibilidade nas buscas do Flathub e atualizações automáticas
• Embora não seja mantenedor nem desenvolvedor de open source, não entende por que tantas distribuições Linux, todas com o mesmo problema de gestão de pacotes, não conseguem unir forças para melhorar e universalizar o Flatpak
  • Como cada distribuição tem sua própria forma de fazer distribuição, acha difícil unificar tudo; vê a diversidade de escolhas como uma vantagem do ecossistema open source e, pessoalmente, prefere gerenciadores de pacote tradicionais do sistema
  • Seguindo essa lógica, só deveria existir o GNOME; defende que a diversidade da comunidade e da tomada de decisão é importante
  • Diz que o Flatpak não tem utilidade nenhuma para si e que não quer ser pressionado a contribuir para software que não usa