Mantenedor do KeePassXC no Debian remove todos os recursos de rede

Controvérsia sobre a remoção de recursos no pacote KeePassXC do Debian

• O mantenedor do pacote KeePassXC no Debian decidiu unilateralmente remover todos os recursos do pacote.
• No Debian sid, o pacote padrão keepassxc passará a incluir apenas o mínimo de funcionalidades, com remoção de rede, agente SSH, plugin de navegador, armazenamento secreto do fdo e outros recursos.
• Se esses recursos forem necessários, será preciso migrar para o pacote keepassxc-full.

Controvérsia sobre o motivo da remoção dos recursos

• No relatório de bug do Debian, a justificativa apresentada é segurança.
• No entanto, a equipe do KeePassXC considera excessivo remover não apenas a rede, mas também quase todos os recursos, como suporte a Yubikey, autoentrada e integração com navegador.
• Há também a opinião de que a remoção de recursos, em vez de reduzir vulnerabilidades, acaba eliminando funcionalidades de que os usuários precisam.

Posição e reação do Debian

• O Debian afirma que remover código não utilizado e recursos desnecessários é a melhor forma de reforçar a segurança após o incidente de comprometimento do liblzma.
• Ainda assim, a decisão foi criticada por ter sido tomada unilateralmente, sem consulta prévia à equipe do KeePassXC.
• Para minimizar a confusão dos usuários, será fornecido um pacote de transição para migrar keepassxc para keepassxc-full.

Opinião do GN⁺

• Remover recursos desnecessários por segurança não é, por si só, uma má ideia, mas retirar de repente funcionalidades usadas pelos usuários sem mudar o nome do pacote não é uma boa abordagem.
• Ao alterar políticas de pacote em uma distribuição como o Debian, o ideal é consultar os desenvolvedores upstream sempre que possível e tentar minimizar a confusão para os usuários.
• O mais recomendável é oferecer separadamente um pacote completo e um pacote mínimo, com nomes bem distintos para que o usuário possa escolher.
• Procurar outro gerenciador de senhas também pode ser uma opção, mas também é importante tentar melhorar o problema com contribuições e cooperação mais ativas com o KeePassXC.
• Ser software livre não significa que o mantenedor do pacote possa fazer o que quiser; é preciso respeitar a opinião da comunidade de usuários e desenvolvedores e buscar uma comunicação transparente.

[GN⁺]

Comentários do Hacker News

Resumo dos comentários do Hacker News

1. Preocupação com remover funcionalidades do projeto upstream e distribuir com o mesmo nome

• Remover funcionalidades implementadas pelo projeto upstream e distribuir com o mesmo nome é algo problemático
• Se a ideia é seguir nessa direção, deveria fazer um fork e distribuir com outro nome
• Foi citado um caso passado em que o mantenedor do pacote Chromium no Debian desativou arbitrariamente a instalação de extensões

2. Opinião de que remover funcionalidades de rede é razoável do ponto de vista de segurança

• Em um gerenciador de senhas, funcionalidades de rede e integração com navegador podem se tornar vulnerabilidades potenciais
• Se apenas um banco de dados confiável for usado, sem funcionalidades relacionadas à rede, mesmo que uma vulnerabilidade seja descoberta, ela não poderá ser explorada
• Também existe no Debian um pacote com a versão completa, incluindo funcionalidades de rede, então quem quiser pode instalar keepassxc-full
• Ainda assim, chamar o upstream de "ruim" não é produtivo, e keepassxc-lite e keepassxc-full podem ser nomes de pacote mais adequados

3. Opinião de que empacotar as versões "full" e "minimal" é a escolha correta

• Deve-se definir uma relação de Conflicts entre as duas versões e usar as tags Provides e Replaces para permitir que o usuário escolha
• Foi levantada a dúvida sobre por que isso não seria a escolha óbvia

4. Questionamento sobre o problema de depender do pacote passim no Arch Linux sem consentimento do usuário

• O pacote fwupd está configurado para depender de passim sem o consentimento do usuário
• O passim executa um servidor web em 0.0.0.0:27500 e usa GnuTLS, que tem muitas vulnerabilidades
• Há preocupação de que essa configuração possa ser explorada

5. Opinião de que funcionalidades principais não devem ser desativadas sem riscos documentados, segundo o princípio da menor surpresa

• As funcionalidades do KeePassXC não se tornam fonte de vulnerabilidade sem intervenção explícita do usuário
• A integração com navegador é muito mais segura do que o acesso à área de transferência e também está alinhada com a visão do projeto
• Os usuários beneficiados por essa mudança seriam pouquíssimos, enquanto para quem usa a integração com navegador isso causa um transtorno sério

6. Argumento de que foi uma decisão errada do mantenedor do pacote Debian, já que seria possível diferenciar sem quebrar os usuários existentes

• Oferecer um KeePassXC sem funcionalidades de rede é algo bom, mas considerar a integração com navegador uma funcionalidade de nicho é uma visão desconectada
• Mais da metade dos usuários de KeePassXC no Debian provavelmente ficará surpresa com essa decisão
• Em última instância, a decisão é do mantenedor do pacote, mas não foi uma boa decisão

7. Citação da opinião do mantenedor do KeePassXC

• Houve relatos de que o novo modelo de empacotamento quebrou o fluxo de trabalho das pessoas
• Também houve um caso em que a funcionalidade de Yubikey foi removida, impedindo o usuário de acessar o banco de dados
• Pessoas que perdem acesso aos seus segredos mais importantes podem agir de forma irracional em um momento de pânico

8. Opinião de que, se um pacote for alterado de forma diferente da intenção do projeto upstream, ele deve ser distribuído com outro nome

• Se o mantenedor downstream alterar o pacote, ele deve distribuí-lo com outro nome e lidar com todos os relatórios de bug causados pela versão modificada

9. Informação de que a discussão mais recente pode ser acompanhada em uma issue do GitHub

10. Observação de que o título está errado

• A postagem original dizia que não apenas as funcionalidades de rede, mas todas as funcionalidades haviam sido removidas, e isso é verdade
• Todas as funcionalidades opcionais, inclusive as offline, foram configuradas para serem desativadas durante a compilação