Flatpaks são *realmente* seguros? Sobre a treta OBS e Fedora

Linux
, , , ,
1

Bom, vamos lá… Publiquei originalmente a pergunta abaixo, no grupo de Facebook “Linux Brasil”, então estou passando para cá as mesmas dúvidas, junto de uma contextualização pra ver a opinião de vocês e se há respostas para essas perguntas, que se relacionam com essa “treta” mais recente do OBS Studio com o projeto Fedora. A quem não sabe, e em resumo: o OBS Studio, projeto de software livre, está ameaçando processar judicialmente o Fedora se o projeto não deixar de redistribuir a sua aplicação no repositório “Fedora Flatpaks”, que por padrão sobrepõe o repositório Flathub nas instalações do Fedora (seja em versões imutáveis ou não). Ou seja, o OBS disponível por padrão nas lojas do Fedora Silverblue, Kinoite, e outras spins, não oferece suporte a uma série de codecs (encoders/decoders) proprietários, como o encoder NVENC, da Nvidia. Assim, o OBS ameaça processar o Fedora se não, ao menos, redistribuir o OBS com um outro nome, assumindo seu direito de marca e um espelhamento de funções, considerando que os usuários de alguma forma estão sendo “levados a erro”, pensando que instalaram o OBS com todas as suas funções.

Disso, decorre todo aquele debate sobre a segurança dos Flatpaks, se a distribuição em formato Flatpak substitui de maneira integral a necessidade de “distribuições tradicionais”, como o Debian ou o próprio Fedora, e se os próprios desenvolvedores (o upstream) são qualificados o bastante para desenvolverem, manterem seus próprios programas e, ainda, manterem as dependências de seus próprios programas.

Nesse sentido, surgiram a mim várias dúvidas:

  1. Quem garante que os pacotes Flatpak são compilados do código-fonte?Quando usamos pacotes nativos, a “garantia” é dos mantenedores da distribuição que usamos, mas e quanto ao Flathub?
  2. Há mantenedores, algum sistema de confiança (ainda que “distro-agnostic”)?
  3. Considerando que o “Flathub Verified” seja feito para isso, ele cumpre de fato esse propósito?

Embora eu veja com bons olhos a containerização, e até por isso que estou usando Silverblue, há uma semana e pouco, confesso que fiquei com essa pulga atrás da orelha depois da polêmica toda. Não me parece ruim que os projetos que há anos vêm redistribuindo, testando pacotes e garantindo a integridade de sistemas com milhares de bibliotecas dinâmicas, sigam sendo responsáveis minimamente por atestar a estabilidade dos seus sistemas, e a garantir a segurança no uso dos pacotes. Sem querer puxar a sardinha pro autor deste artigo, considero que é válida a preocupação.

Imaginem projetos grandes relativamente, como o próprio OBS (em número de funções). Um projeto como OBS, Kdenlive, quando empacotado para Flatpak, por segurança e idealmente, deve ter um(a) colaborador(a) específico(a) que esteja na função de garantir a atualização das bibliotecas desse pacote (ou, como é nesse sistema e no Windows, os “runtimes”). Creio que a garantia de atualização de bibliotecas deveria ser um critério para afirmar a segurança dos pacotes. O recurso recente que permitirá daemons (serviços) rodarem de dentro de um flatpak aumentam a relevância dessa preocupação.

Mas enfim, o que pensam a respeito? Chegou a hora do upstream tomar conta integralmente da distribuição dos programas (ou de uma boa fatia deles)?

2

o problema aí não é ser flatpak mas não vir com os codecs que vem no repositório do flathub.

2 curtidas
3

Eu não gosto dos Flatpaks

1- O tamanho dos pacotes é muito grande.
Não adianta ter BTRFS com compressão ou somatórios de vários pacotes com lib compartilhada que ainda vai ocupar mais espaço.

2- Muitas aplicações não funcionam direito.
Exemplo: O Sandbox dos navegadores fica limitado, o SELinux não consegue filtrar direito e não tem integração com o resto do sistema (Warsaw, gnome-extensions, controle de mídia, temas), ou simplesmente não funcionam mesmo.

3- Sandbox não muito útil.
Várias aplicações vem com o /home inteiro liberado. Belo sandbox.
Aplicações mais importantes (como navegadores) já vem com sandbox fora do Flatpak, e isso volta no item 2, alguns sandbox nativos não funcionam como deveriam no Flatpak, além de atrapalhar o SELinux.

Sobre o sandbox dos navegadores e SELinux no flatpak:

Considero o SELinux confined user mais eficiente como sandbox do que o Flatpak.

4- Não tem tanta confiança quanto pacotes das distros.
Se o Fedora tem 1- O flatpak do Fedora em si e 2- flatpaks do flathub em uma lista branca, então é porque não dá para confiar tanto no flathub quanto nas distros.

5- Tira controle das distros.
Usando esse exemplo mesmo do OBS, antigamente o desenvolvedor do aplicativo fazia o código e a distro compilava pro usuário. Hoje o dev faz os 2 com flatpak, assim removendo poder das distros de modificar o código que é aberto e impedindo alguma melhoria específica para a distro.

Considero usar primeiramente os pacotes .deb/.rpm das distros e em segundo (ou terceiro) caso o flatpak.

SObre essa polêmica do OBS:

O Fedora tem direito de empacotar o OBS, por ele ser SL.
O OBS tem direito a imagem deles.
Então pode ser que o Fedora tenha que fazer rebranding.

A culpa aqui é dos usuários que reclamam que o OBS do Fedora não está funcionando direto pro OBS, e não pro Fedora.

Tem vários aplicativos que são os próprios dev da aplicação que fazem o flatpak, esses dão para confiar mais.

2 curtidas
4

Sim, mas entendo que a raiz dessa discussão toda é: deve ainda haver intervenção do “downstream” (da distribuição) no “upstream”, quando se trata de Flatpaks? E aí acredito que dá pra reacender toda essa “velha” polêmica.

1 curtida
5

Tem muita coisa misturada que não tem a ver com a sua pergunta, vamos por partes:

Flatpaks são realmente seguros?

Depende, são relativamente seguros, ou seja mais seguros que rodar direto no sistema, porém a problemática é que são aplicativos, aplicativos nunca serão seguros é uma falha de design intrínseca, aplicativos são basicamente extensões do Shell como resultado eles sempre vão acessar mais do que podem e sempre vão ser inseguros por uma série de motivos que daria um post a parte… Mas dentre as formas de se ter aplicativos Flatpaks são minimamente seguros

Sim isso é uma questão frequentemente ignorada, software livre é diferente de domínio público, basicamente o código é livre as marcas não, você pode redistribuir modificando ou não o código porém o software em si (código+marca) é um produto ainda que não se cobre nada por ele

Não, não substitui nenhum formato é perfeito, o que o Flatpak substitui é a pasta /opt (e até hoje eu acho estranho não serem instalados em /opt por padrão), muitos pacotes não podem funcionar bem em Flatpak e está tudo bem a distribuição via empacotamento tradicional não substitui Flatpak também, o mundo é assim e isso é a parte divertida

Evidentemente que sim o estrago foi feito na década de 1980

Isso depende, o Flatpak usa ostree que por sua vez funciona exatamente como o git só que otimizado para binários, isso trás um ponto interessante, internamente no Flatpak você não tem /bin/bash você tem /objects/[seção]/hash ou seja, você consegue comparar com o binário original do desenvolvedor se houve modificações, caso seja modificado a hash será diferente, mas para isso é necessário acesso ao arquivo de construção do Flatpak desejado, para nossa alegria os da Flathub e do Fedora são abertos

Ter tem mas cai no mesmo “problema” de confiar na Flathub, não tem como verificar w de novo, pela forma como o mecanismo de aplicativos foi lançado lá em 1980

Não, Flathub Verified serve para você saber que quem mantém o Flatpak verificado ou é o próprio desenvolvedor ou alguém de confiança dele

4 curtidas
7

Apesar de usar o Flatpak, concordo e muito com as ressalvas contidas nesse e artigos semelhantes.

Honestamente acho bizarro uma distribuição criar Flatpaks próprios. A polêmica mostra que isso só combina o pior dos dois mundos: divergências entre bibliotecas básicas (um “runtime” uniforme não deveria ser um dos principais atrativos do Flatpak?) e uso ineficiente de espaço pela falta da flexibilidade de um gerenciador de pacotes tradicional.

No caso do Flathub especificamente, vem da equipe que mantém o robô compilador do Flathub, que por sua vez puxa de quem mantém o “manifest” do pacote. Quase sempre esses manifests são mantidos num repositório sob o nome do organização do Flathub (ex. RPCS3), mas pacotes específicos como o OBS utilizam subpastas do repositório oficial (veja a seção “Links” da página do pacote no Flathub).

Não sei bem como são os ritos de iniciação para poder acessar e a hierarquia do controle de qualidade na organização do Flathub, no entanto.

1 curtida