Mantenedor do KeePassXC no Debian remove todos os recursos de rede

(fosstodon.org/@keepassxc)

1 pontos por GN⁺ 2024-05-12 | 1 comentários | Compartilhar no WhatsApp

Se o pacote keepassxc do Debian passar a ser um pacote de funcionalidade mínima, os usuários que quiserem manter os recursos atuais terão de migrar para keepassxc-full
O escopo da remoção não se limita à rede e inclui YubiKey, auto-type, integração com navegador, agente SSH, segredos FDO, download de favicon e HIBP
A descrição do pacote no Debian informa que o keepassxc padrão oferece apenas “bare minimal functionality” e classifica rede, agente SSH, plugin de navegador e armazenamento de segredos FDO como complexidade de segurança
O aviso da mudança será comunicado por NEWS.Debian.gz e apt-listchanges, e usuários do stable devem verificar as notas de lançamento
O nome do pacote e a forma de transição ainda podem ser ajustados; após o Trixie, há discussão sobre fazer apt install keepassxc mostrar as duas opções

Mudança no pacote `keepassxc` do Debian

A equipe do KeePassXC informou aos usuários do Debian que o mantenedor do pacote keepassxc pretende remover uma grande quantidade de recursos
Quando a mudança sair de testing/sid, os usuários que precisarem dos recursos atuais terão de migrar para keepassxc-full
O relatório de bug do Debian parece indicar apenas a desativação de rede, mas a equipe do KeePassXC contesta isso e afirma que a mudança real está mais próxima de uma remoção geral de recursos além da rede

Escopo dos recursos removidos

Segundo a equipe do KeePassXC, os recursos a serem removidos são os seguintes
- YubiKey
- auto-type
- integração com navegador
- agente SSH
- segredos FDO
- rede
- download de favicon
- HIBP

Descrição do pacote Debian e justificativa

A descrição do pacote keepassxc no Debian sid informa que o pacote padrão inclui apenas a funcionalidade mínima
Essa descrição trata rede, agente SSH, plugin de navegador e armazenamento de segredos FDO como complexidade de segurança, orientando quem realmente precisar desses recursos a usar keepassxc-full
Foi compartilhado o relatório de bug do Debian relacionado #953529 - keepassxc: Compiling with disable networking support

Posição do mantenedor do Debian

O mantenedor do Debian apontou /usr/share/doc/<package>/NEWS.Debian.gz como o primeiro lugar para verificar mudanças inesperadas
Usuários de testing/unstable podem ver as mudanças automaticamente se tiverem apt-listchanges instalado, e usuários do stable devem ler as notas de lançamento
Ele afirmou que essa decisão foi discutida durante um ano e que, após o caso xz-utils, houve uma tendência a reduzir ao máximo o código incluído por padrão
O mantenedor também disse não acreditar que haja grande sobreposição entre os usuários que querem Debian, KeePassXC e um gerenciador de senhas com muitos recursos ao mesmo tempo
Ele descreveu como sem sentido colocar “buracos” em um gerenciador de senhas apenas local

Problema de comunicação entre upstream e downstream

Um usuário apontou como problema o fato de que, mesmo após uma discussão longa, os desenvolvedores upstream pareceram totalmente surpresos
O mantenedor do Debian respondeu que isso era um assunto interno do projeto Debian e que havia pedido opiniões a outros desenvolvedores Debian no IRC
Ele explicou que já conhecia a posição do upstream, que o upstream havia deixado o IRC há alguns anos e que só empacotar novas versões já consumia toda a energia disponível
A equipe do KeePassXC e alguns usuários demonstraram preocupação de que a decisão downstream possa gerar uma onda de relatórios de bug e confusão direcionados ao upstream

Nome do pacote e direção da transição

Vários usuários sugeriram que, em vez de transformar keepassxc no pacote de funcionalidade mínima, seria menos confuso usar nomes como keepassxc-minimal ou keepassxc-light e manter o keepassxc atual com todos os recursos
Uma das propostas tinha a seguinte estrutura
- keepassxc-light
- keepassxc-full
- keepassxc dependendo de keepassxc-full como pacote de transição
- explicação da mudança em NEWS.Debian
O mantenedor do Debian respondeu que a mudança de nome depende da aprovação do ftpteam e que, para a transição no Trixie, essa proposta pode ser a melhor opção
Após o Trixie, também foi levantada a possibilidade de remover o pacote de transição e fazer apt install keepassxc mostrar as duas opções

1 comentários

GN⁺ 2024-05-12

Opiniões no Hacker News

Distribuir com o mesmo nome depois de remover em massa funcionalidades que o upstream colocou no software é, na melhor das hipóteses, suspeito
Se quiserem seguir nessa direção, deveriam distribuir como um fork com outro nome, para que o upstream não continue sendo importunado por problemas relatados por usuários
Isso lembra quando, no passado, o mantenedor do Chromium no Debian desativou unilateralmente a instalação de extensões, até que o patch acabou sendo revertido
Também me faz lembrar de muito tempo atrás, quando o Debian removeu a interface do kernel que carregava firmware binário em placas de rede, e minha rede quebrou
- Na prática, a única coisa feita foi mudar o parâmetro de build XC_ALL para OFF [0], e esse valor também é o padrão no CMakeLists.txt do upstream 1
  Se o upstream considera esse recurso tão importante, deveria corrigir primeiro o valor padrão
  É possível que usuários fiquem confusos quando o recurso parar de funcionar após a atualização, mas o pacote sem sufixo corresponder ao padrão do upstream é, por si só, bastante razoável
  
  [0] https://salsa.debian.org/debian/keepassxc/-/commit/7d6d16e3f...
  1 https://github.com/keepassxreboot/keepassxc/blob/develop/CMa...
- O papel de um mantenedor é mais do que copiar e colar o upstream
  Ele tem o direito de decidir o que é apropriado para os usuários finais da distribuição
  Neste caso, parece haver uma justificativa de segurança razoável, e também é oferecido um pacote alternativo
- O Debian parece ser a única distribuição com uma atitude estranha de ignorar o upstream
  Em dois projetos upstream que mantenho, o Debian também mudou unilateralmente os nomes dos pacotes
  De um deles só fiquei sabendo muito tempo depois; no outro, mesmo eu tendo me oposto explicitamente, fizeram de um jeito completamente sem sentido
  No fim, quem precisa explicar aos usuários sou eu
  
  Edit: dá para ver aqui a arrogância do Julian, do lado do Debian: https://github.com/keepassxreboot/keepassxc/issues/10725#iss... — é disso que estou falando
- Eles não “arrancaram” algo que o upstream criou
  Estão distribuindo uma versão sem plugins e criando uma versão -full com os plugins incluídos
  Se os plugins vêm ativados por padrão, então não são plugins, são funcionalidades embutidas, e este é o jeito certo
- Se a Apple dissesse “modificamos seu app porque achamos que é melhor para a segurança”, as pessoas apareceriam com tochas e forcados
  Mas, quando um mantenedor deb faz isso, vira tema de debate
  Se há um problema de segurança, a versão insegura nem deveria ser oferecida; mas nem é esse o caso aqui
  Em um mundo tipo App Store, o papel do mantenedor precisa mudar
  O trabalho é fazer o software funcionar na distribuição, não criar um quase-fork de acordo com preferências próprias mantendo o mesmo nome
Parece uma decisão bastante razoável
Funcionalidades de rede e integração com o navegador são grandes brechas em potencial e pontos de entrada para ataques
Se você executa apenas um banco de dados confiável, sem recursos relacionados a rede, mesmo que uma vulnerabilidade seja descoberta, deveria ser quase impossível abusar da ferramenta — uma característica muito desejável para uma ferramenta tão crítica quanto um gerenciador de senhas
O mantenedor original também concorda 1
O pacote completo com rede ativada também está no Debian, então usuários que quiserem só precisam fazer apt install keepassxc-full para usar todos os recursos de rede
Ainda assim, chamar o upstream de “crappy”[0] não é uma postura produtiva para um mantenedor de pacotes, e os nomes keepassxc-lite e keepassxc-full provavelmente seriam mais claros para usuários do Debian do que keepassxc e keepassxc-full

[0] https://github.com/keepassxreboot/keepassxc/issues/10725#iss...

1 https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
- Muitas coisas são grandes brechas em potencial e pontos de entrada para ataques e, ao mesmo tempo, também são úteis
  “Utilidade” pode aumentar a segurança
  Porque, se um gerenciador de senhas é difícil de usar, as pessoas param de usá-lo
  Olhando melhor, também não está claro se usar a área de transferência é necessariamente mais seguro do que a integração com o navegador
  Só erros de copiar/colar já podem compensar boa parte do ônus de segurança da integração com o navegador
  Há muito tempo, fiz um trabalho terceirizado em uma grande empresa; os notebooks dos gerentes de contas tinham senha de criptografia de disco, senha de login do Windows e senha de login no AD, todas precisavam ser diferentes, trocadas a cada poucos meses e com requisitos de complexidade pesados
  Em todos os notebooks que vi, sem exceção, havia um post-it com as três senhas anotadas
  O ponto é que segurança hipotética de entusiasta de segurança não é o mesmo que segurança no mundo real
  Pelo menos nem sempre é, e aqui são necessárias concessões reais

1: Nós, como contratados externos, fazíamos a manutenção dos notebooks de alguns funcionários
Originalmente isso não deveria acontecer, mas passar pelo sistema de TI da empresa demorava demais por causa da burocracia, então era muito mais rápido e fácil
Era esse tipo de empresa
Isso por si só, obviamente, também era um “risco de segurança”, porque não faz sentido um técnico qualquer de uma loja de informática mexer em um notebook com dados ultrassecretos da empresa
Mas acho que não havia tanta coisa assim a proteger. Eram algo como números de vendas/clientes, informações úteis apenas para um grupo muito restrito de pessoas

Há um aspecto em que a integração com o navegador aumenta a segurança em relação a copiar/colar manualmente
A extensão do navegador verifica a URL da página antes de preencher as credenciais, enquanto copiar/colar manualmente é vulnerável a domínios com erro de digitação ou phishing com caracteres homógrafos
Concordo que recursos de rede e integração com o navegador são grandes brechas em potencial, mas, como disseram os participantes da issue no GitHub, é importante notar que há pouquíssimos testes da build reduzida em comparação com a build completa, e combinações arbitrárias de flags de build não são testadas de forma alguma
Como também foi mencionado em outros lugares, uma das flags “opcionais” desativadas é o suporte a yubikey, e por causa disso usuários que atualizaram para o pacote recém-quebrado estão ficando bloqueados fora do seu gerenciador de senhas
Só religar essa única flag já deixa o pacote em um estado que, na prática, ninguém testa
Se a premissa era mover os usuários existentes para keepassxc-full, concordo que o nome keepassxc-lite teria evitado o problema
Mas esse é exatamente o ponto central
É razoável tornar a solução mais segura o padrão, mas o mantenedor não deve quebrar funcionalidades existentes a menos que o upstream ou os usuários queiram isso, e especialmente não deve deixar usuários bloqueados fora do gerenciador de senhas
Postar “crappy” no GitHub foi tão grosseiro que, se eu usasse Debian, eu reconsideraria o uso
Se o pacote está cheio de funcionalidades tão porcarias, não sei por que se dar ao trabalho de mantê-lo
Seria melhor simplesmente removê-lo e deixar os usuários descobrirem por conta própria como instalar direito
Tenho pena dos desenvolvedores do KeePassXC; manter um projeto open source já é difícil, e ainda precisam lidar com esse tipo de coisa
No momento em que vi a expressão crappy, perdi imediatamente o respeito por julian-klode
A solução proposta por drawks parece claramente ser a escolha correta:

A solução adequada provavelmente seria empacotar tanto uma versão "-full" quanto uma "-minimal" do software, definir uma relação Conflicts entre os dois pacotes nos campos de metadados dos pacotes Debian, marcar ambos como Provides: keepassxc e, na build -full, também adicionar a tag Replaces: keepassxc. Assim, durante a atualização de pacotes, usuários existentes receberiam a versão que continua oferecendo os recursos do pacote que está sendo atualizado/substituído, e novos usuários poderiam escolher diretamente qual versão instalar

https://github.com/keepassxreboot/keepassxc/issues/10725#iss...

Não sei por que isso poderia não ser uma opção óbvia
- Porque o mantenedor tem sua própria opinião e queria explicitamente mudar o padrão
- Isso não só é a escolha óbvia, como foi exatamente assim que aconteceu de fato no Debian: https://salsa.debian.org/debian/keepassxc/-/commit/7d6d16e3f...
  
  O post original é só um clickbait mal escrito
  Nada foi removido; apenas foi movido para o pacote keepassxc-full
Enquanto isso, no lado do Arch, o pacote fwupd, que provavelmente está instalado em uma parcela considerável da base de usuários, passou discretamente a depender do passim, e o passim sobe um servidor web aberto em 0.0.0.0:275001 sem consentimento explícito do usuário
Além disso, o passim usa GnuTLS, famoso por ter mais buracos que queijo suíço 2
Acho isso realmente absurdo, e não ficaria surpreso se houvesse um exploit do tipo xz escondido em algum ponto da cadeia
- Nem é preciso procurar pelo fwupd
  O onipresente systemd-resolved pode, quando solicitado, abrir na porta 5355 um servidor LLMNR, também chamado de mDNS e parte da antiga linhagem Microsoft NetBIOS
  Na era da Internet das Coisas, em que todo mundo pode acessar minha LAN, agora estão fazendo o Linux entrar nessa bagunça também
  
  A correção do fwupd é assim, já que o arquivo de configuração padrão é de baixa qualidade e nem há valores padrão comentados:
```
# /etc/fwupd/fwupd.conf  
[fwupd]  
P2pPolicy=none  
```
  A correção do resolved é descomentar LLMNR=no em /etc/systemd/resolved.conf, e provavelmente você também vai querer DNSStubListener=no
  Bons valores padrão seriam estes:
```
# /etc/systemd/resolved.conf  
[Resolve]  
DNS=9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net 2620:fe::fe#dns.quad9.net 2620:fe::9#dns.quad9.net  
FallbackDNS=127.0.0.1 ::1  
Domains=~.  
DNSOverTLS=yes  
LLMNR=no  
DNSStubListener=no  
```
- Bom saber
  Acho que isso poderia virar um post separado
O mantenedor do pacote deve agir de acordo com o princípio da menor surpresa e não desativar funcionalidades essenciais, a menos que haja um risco documentado, ou ao menos plausível
A palavra “plugin” aparece 25 vezes nesta seção de comentários, mas não é disso que se trata aqui
O KeePassXC tem muitos recursos, mas não parece haver nada que, por si só, sem ação explícita do usuário, seja uma fonte provável de vulnerabilidades
A integração com o navegador precisa primeiro ser ativada antes de ser configurada, e os outros recursos desativados por essa flag provavelmente são iguais, então um pacote -minimal teria sido mais adequado
O transtorno sério para quem usava a integração com o navegador é muito maior do que o benefício para um número minúsculo de usuários que, em algum futuro incerto, se beneficiaria dessa mudança
A integração com o navegador também costuma ser um recurso muito mais seguro do que o acesso à área de transferência
Isso também não parece estar alinhado à visão do projeto:

O objetivo é criar um aplicativo que qualquer pessoa possa usar, mas que também ofereça recursos avançados para quem precisa deles
Como seria possível criar essa distinção sem quebrar os usuários existentes, é difícil ver isso como outra coisa que não uma decisão ruim do mantenedor do pacote Debian
É certamente bom poder usar o KeepassXC sem recursos de rede, mas tratar a integração com o navegador como um recurso de nicho é extremamente desconectado da realidade
Eu apostaria dinheiro que mais da metade dos usuários do KeepassXC no Debian hoje, provavelmente muito mais, quer os recursos que serão desativados sem aviso por causa dessa abordagem
No fim, a decisão cabe a eles, mas isso não significa que seja uma boa decisão; eu acho que não é
Palavras do mantenedor do KeePassXC:

Antes de esta thread começar, recebemos três relatos de que esse novo esquema de empacotamento quebrou o fluxo de trabalho das pessoas. Um deles foi de um usuário que não conseguia mais abrir seu banco de dados porque o recurso de yubikey tinha sido removido. Pense nisso por um instante. Uma pessoa impedida de acessar seus segredos mais importantes pode entrar em pânico e, às vezes, agir de forma irracional

https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
- Se você usa um gerenciador de senhas offline e não tem backup, pode considerar tudo perdido
  Isso soa como chantagem emocional
  Nem sei quantas vezes já vi alguém perder tudo por falha de hardware, atualização que quebrou o sistema operacional, uso de dd no drive errado etc.
Se um mantenedor downstream quiser modificar um pacote de uma forma diferente da intenção do projeto upstream, acho que deve distribuí-lo com outro nome e lidar diretamente com todos os relatórios de bugs causados por essa versão modificada
- A build padrão vem com networking OFF
  O mesmo vale para Yubikey, integração com navegador etc.
  
  -DWITH_XC_NETWORKING=[ON|OFF] Enable/Disable Networking support (e.g., favicon downloading) (default: OFF)
  
  https://github.com/keepassxreboot/keepassxc/blob/develop/INS...
- Como a opção de build WITH_XC_NETWORKING vem desativada por padrão, fica claro que os desenvolvedores pretendiam que essa configuração fosse uma configuração de build válida
- Sei que, normalmente, isso não é seguido à risca, mas o fluxo padrão original é esse
  Se você usa um pacote fornecido pela distribuição e encontra um bug, deveria abrir o bug no pacote da distribuição; o mantenedor analisa e, se for um bug vindo do upstream, encaminha para o projeto upstream
  Esse método é útil porque 1. o mantenedor do pacote conhece aquele pacote e pode fazer a triagem e a análise iniciais, talvez até corrigir antes de chegar ao upstream, e 2. como foi dito, pacotes de distribuição frequentemente incluem patches, então o mantenedor precisa verificar se o problema está no empacotamento ou no código-fonte upstream
  Infelizmente, muitos usuários reportam primeiro ao upstream
  Então, na prática, é uma preocupação válida, mas originalmente não deveria ser assim
- Ou então deve ficar claro para o usuário final que se trata de um pacote sem suporte
  Por exemplo, exibindo-o como KeePassXC-Debian ou KeePassXC-Unsupported, removendo do About os contatos ou o site dos desenvolvedores e substituindo por informações de suporte do Debian
  Pequenas alterações downstream para adequação ao sistema operacional são aceitáveis
  Mas modificar o app para remover recursos essenciais e fazer os desenvolvedores upstream receberem uma enxurrada de reclamações não é aceitável
- Não entendo por que você comenta sem nem ler o texto linkado de 200 caracteres
  O mantenedor ativou todos os plugins, incluindo os relacionados a rede, no pacote keepassxc-full, e deixou o pacote keepassxc apenas com os recursos básicos, com uma postura de segurança muito melhor
  Isso é claramente totalmente aceitável e está dentro da autoridade do mantenedor
  A reclamação toda é que isso é uma mudança
Para quem estiver interessado, esta issue no GitHub parece conter os comentários mais recentes

https://github.com/keepassxreboot/keepassxc/issues/10725
- A visão do mantenedor do Debian, Julian Klode, é bastante afiada:
  
  Sinto muito, mas isso não vai acontecer. Foi um erro compilar e distribuir todos os plugins por padrão. Como os usuários irritantemente não leem o arquivo NEWS que deveriam ler, será doloroso por mais ou menos um ano, mas há muito pouco que possa ser feito.
  
  É nossa responsabilidade oferecer aos usuários, por padrão, a opção mais segura possível. Todos esses recursos são desnecessários e não pertencem de fato a um gerenciador de banco de dados de senhas local. Toda essa direção de desenvolvimento está completamente errada.
  
  Os usuários que precisam desse lixo podem instalar a versão lixo, mas isso obviamente aumenta o risco de ataques por contribuidores ocasionais.
O título está errado
O texto original dizia que o mantenedor removeu não apenas os recursos de rede, mas todos os recursos, e isso estava correto, porque todos os recursos opcionais, até os totalmente offline, foram desativados durante a build