El mantenedor de KeePassXC en Debian elimina todas las funciones de red

(fosstodon.org/@keepassxc)

1 puntos por GN⁺ 2024-05-12 | 1 comentarios | Compartir por WhatsApp

Si el paquete keepassxc de Debian pasa a ser un paquete de funcionalidad mínima, los usuarios que quieran conservar las funciones actuales deberán cambiarse a keepassxc-full
La eliminación no se limita a networking: también incluye YubiKey, auto-type, integración con navegadores, SSH agent, FDO secrets, descarga de favicons y HIBP
La descripción del paquete en Debian indica que el keepassxc predeterminado solo ofrece “funcionalidad mínima básica” y clasifica networking, SSH agent, plugins de navegador y FDO secret storage como complejidad de seguridad
El aviso del cambio se comunicará mediante NEWS.Debian.gz y apt-listchanges; los usuarios de stable deberán revisar las notas de la versión
El nombre del paquete y la forma de transición aún podrían ajustarse, y se menciona la posibilidad de que después de Trixie apt install keepassxc muestre dos opciones

Cambios en el paquete `keepassxc` de Debian

Team KeePassXC informó a los usuarios de Debian que el mantenedor del paquete keepassxc planea eliminar una gran cantidad de funciones
Si el cambio llega más allá de testing/sid, los usuarios que necesiten las funciones actuales deberán cambiarse a keepassxc-full
Aunque el reporte de bug de Debian parece tratar sobre desactivar networking, Team KeePassXC refuta esto y afirma que el cambio real se acerca más a una eliminación completa de funciones, más allá de networking

Alcance de las funciones eliminadas

Según Team KeePassXC, las funciones que se eliminarán son las siguientes
- YubiKey
- auto-type
- integración con navegadores
- SSH agent
- FDO secrets
- networking
- descarga de favicons
- HIBP

Descripción del paquete Debian y justificación

La descripción del paquete keepassxc en Debian sid indica que el paquete predeterminado solo incluye funciones mínimas
Esa descripción considera networking, SSH agent, plugins de navegador y FDO secret storage como complejidad de seguridad, e indica usar keepassxc-full si son estrictamente necesarios
Se compartió como reporte de bug relacionado de Debian #953529 - keepassxc: Compiling with disable networking support

Postura del mantenedor de Debian

El mantenedor de Debian señaló /usr/share/doc/<package>/NEWS.Debian.gz como el primer lugar donde revisar cambios inesperados
Los usuarios de testing/unstable pueden ver automáticamente los cambios si tienen instalado apt-listchanges, y los usuarios de stable deben leer las notas de la versión
Afirmó que esta decisión se discutió durante un año y que, tras el incidente de xz-utils, se inclinaron por reducir al máximo el código incluido por defecto
El mantenedor no considera que haya una gran superposición entre los usuarios que quieren Debian, KeePassXC y un gestor de contraseñas con muchas funciones al mismo tiempo
Expresó que no tiene sentido poner “agujeros” en un gestor de contraseñas solo local

Problemas de comunicación entre upstream y downstream

Un usuario cuestionó que, pese a que la discusión duró mucho tiempo, los desarrolladores upstream parecieran estar completamente sorprendidos
El mantenedor de Debian respondió que se trata de un asunto interno del proyecto Debian y que pidió opiniones a otros desarrolladores de Debian en IRC
Explicó que ya conocía la postura de upstream, que upstream dejó IRC hace algunos años y que apenas tiene energía suficiente para empaquetar las nuevas versiones
Team KeePassXC y algunos usuarios temen que esta decisión de downstream provoque que lleguen a upstream reportes de bugs y confusión

Nombre del paquete y dirección de la transición

Varios usuarios sugirieron que, en lugar de convertir el keepassxc predeterminado en un paquete de funcionalidad mínima, sería menos confuso usar un nombre como keepassxc-minimal o keepassxc-light y mantener el keepassxc existente con todas las funciones
Una propuesta planteaba la siguiente estructura
- keepassxc-light
- keepassxc-full
- keepassxc como paquete de transición que depende de keepassxc-full
- explicación del cambio mediante NEWS.Debian
El mantenedor de Debian respondió que el cambio de nombre depende de la aprobación de ftpteam, y que la opción del paquete de transición para Trixie podría ser la mejor propuesta
También se mencionó la posibilidad de que, después de Trixie, se elimine el paquete de transición y apt install keepassxc muestre dos opciones

1 comentarios

GN⁺ 2024-05-12

Opiniones de Hacker News

Distribuir con el mismo nombre software al que se le quitaron masivamente funciones que upstream había incluido resulta sospechoso, en el mejor de los casos.
Si quieren ir por ese camino, deberían distribuirlo como un fork con otro nombre, para que upstream no siga recibiendo quejas de usuarios por esos problemas.
Me recuerda a cuando, hace tiempo, el mantenedor de Chromium en Debian deshabilitó unilateralmente la instalación de extensiones y al final el parche se revirtió.
También me hace pensar en algo mucho más antiguo: cuando Debian eliminó la interfaz del kernel para cargar firmware binario en tarjetas de red y me rompió la red.
- En realidad, lo único que hicieron fue cambiar a OFF el parámetro de compilación XC_ALL [0], y ese valor también es el predeterminado en el CMakeLists.txt de upstream 1.
  Si upstream considera que esta función es tan importante, debería empezar por corregir el valor predeterminado.
  Es posible que los usuarios se confundan porque una función dejó de funcionar después de actualizar, pero que el paquete sin sufijo coincida con los valores predeterminados de upstream es, en sí mismo, bastante razonable.
  
  [0] https://salsa.debian.org/debian/keepassxc/-/commit/7d6d16e3f...
  1 https://github.com/keepassxreboot/keepassxc/blob/develop/CMa...
- El rol del mantenedor es más que copiar y pegar upstream.
  Tiene autoridad para juzgar qué es apropiado para los usuarios finales de la distribución.
  En este caso parece haber una justificación de seguridad razonable, y además se ofrece un paquete alternativo.
- Debian parece ser la única distribución con una actitud rara de ignorar a upstream.
  En dos proyectos upstream que mantengo, Debian también cambió unilateralmente los nombres de los paquetes.
  De uno me enteré mucho tiempo después; en el otro me opuse explícitamente, pero aun así avanzaron de una manera completamente absurda.
  Al final, quien tiene que explicárselo a los usuarios soy yo.
  
  Edición: aquí se puede ver la arrogancia de Julian, del lado de Debian: https://github.com/keepassxreboot/keepassxc/issues/10725#iss... — a esto me refiero.
- No “recortaron” lo que creó upstream.
  Distribuyen una versión sin plugins y crearon una versión -full que incluye los plugins.
  Si el plugin viene activado por defecto, entonces no es un plugin sino una función integrada, y esta forma de hacerlo es correcta.
- Si Apple hubiera dicho “modificamos tu app porque creemos que es mejor para la seguridad”, la gente habría salido con antorchas y horcas.
  Pero si lo hace un mantenedor deb, se vuelve tema de debate.
  Si hay un problema de seguridad, la versión insegura directamente no debería ofrecerse, pero este caso ni siquiera es eso.
  En un mundo tipo App Store, el rol del mantenedor debería cambiar.
  Su trabajo es hacer que el software funcione en la distribución, no crear un cuasi-fork a su gusto manteniendo el mismo nombre.
Me parece una decisión bastante razonable.
Las funciones de red y la integración con el navegador son grandes agujeros potenciales y puntos de entrada para ataques.
Si solo ejecutas una base de datos de confianza sin funciones relacionadas con red, aunque se descubra una vulnerabilidad debería ser casi imposible abusar de la herramienta, y esa es una característica muy deseable en una herramienta tan crítica como un gestor de contraseñas.
El mantenedor original también está de acuerdo 1.
El paquete completo con red habilitada también está en Debian, así que quien lo quiera solo tiene que hacer apt install keepassxc-full para usar todas las funciones de red.
Dicho eso, llamar “crappy”[0] a upstream no es una actitud productiva para un mantenedor de paquetes, y los nombres keepassxc-lite y keepassxc-full habrían sido más claros para los usuarios de Debian que keepassxc y keepassxc-full.

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

1 https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
- Muchas cosas son grandes agujeros potenciales y puntos de entrada para ataques, y al mismo tiempo también son útiles.
  La “utilidad” puede mejorar la seguridad.
  Porque si un gestor de contraseñas es difícil de usar, la gente deja de usarlo.
  Viéndolo un poco más, tampoco queda claro que usar el portapapeles sea necesariamente más seguro que la integración con el navegador.
  Un simple error al copiar y pegar podría compensar buena parte de la carga de seguridad que implica la integración con el navegador.
  Hace mucho trabajé como contratista en una empresa grande, y las laptops de los administradores de cuentas tenían una contraseña para el cifrado de disco, una contraseña de inicio de sesión de Windows y una contraseña de inicio de sesión de AD; todas tenían que ser distintas, cambiarse cada pocos meses y cumplir requisitos de complejidad bastante severos.
  En todas las laptops que vi, sin excepción, había un post-it con las tres contraseñas escritas.
  El punto es que la seguridad hipotética de fanáticos de la seguridad no es lo mismo que la seguridad real en la práctica.
  Al menos no siempre, y aquí hacen falta compromisos reales.

1: Como contratistas externos, nos encargábamos del mantenimiento de las laptops de algunos empleados.
En teoría no debería haberse hecho así, pero pasar por los sistemas de TI de la empresa tardaba demasiado por la burocracia, así que era mucho más rápido y fácil.
Era ese tipo de empresa.
Esto, por supuesto, también era un “riesgo de seguridad” en sí mismo, porque no corresponde que un técnico cualquiera de una tienda de computadoras toque laptops con datos ultrasecretos de la empresa.
Aunque creo que no había tanto que proteger. Eran más que nada cifras de ventas/clientes, información útil solo para un grupo muy limitado de personas.

Hay un aspecto en el que la integración con el navegador mejora la seguridad frente a copiar/pegar manualmente.
La extensión del navegador verifica la URL de la página antes de completar las credenciales, mientras que copiar/pegar manualmente es vulnerable a dominios con errores tipográficos o a phishing con caracteres homógrafos.
Estoy de acuerdo en que las funciones de red y la integración con el navegador son agujeros potenciales importantes, pero, como dijeron los participantes del issue de GitHub, es importante que casi no haya pruebas de builds reducidas en comparación con el build completo, y que las combinaciones arbitrarias de flags de build no se prueben en absoluto.
Como también se comentó en otros lugares, uno de los flags “opcionales” desactivados es el soporte para yubikey, y por eso usuarios que actualizaron al nuevo paquete roto están quedando bloqueados fuera de su gestor de contraseñas.
Con solo volver a activar ese flag ya se queda en un estado que en la práctica nadie prueba.
Si la premisa era mover a los usuarios existentes a keepassxc-full, coincido en que el nombre keepassxc-lite habría evitado el problema.
Pero justamente ese es el punto.
Es razonable tomar la solución más segura como valor predeterminado, pero el mantenedor no debería romper funcionalidades existentes si upstream o los usuarios no lo quieren, y en especial no debería dejar a los usuarios bloqueados fuera de su gestor de contraseñas.
Publicar “crappy” en GitHub fue tan grosero que, si yo usara Debian, habría reconsiderado usarlo.
Si el paquete está lleno de funciones tan pésimas, no entiendo por qué se molestan en mantenerlo.
Mejor eliminarlo y dejar que los usuarios averigüen cómo instalarlo correctamente.
Me dan pena los desarrolladores de KeepassXC; mantener un proyecto open source ya es difícil y encima tienen que lidiar con esto.
En cuanto vi la expresión crappy, perdí de inmediato el respeto por julian-klode.
La solución que propuso drawks parece claramente la opción correcta:

La solución adecuada probablemente sería empaquetar tanto la versión "-full" como la "-minimal" del software, definir una relación Conflicts entre ambos paquetes mediante el campo de metadatos de paquetes de Debian, etiquetar ambos como que Provides keepassxc, y agregar también una etiqueta Replaces: keepassxc al build -full. Así, durante la actualización de paquetes, los usuarios existentes recibirían la versión que sigue ofreciendo las funciones del paquete que se actualiza/reemplaza, y los usuarios nuevos podrían elegir qué versión instalar.

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

No veo por qué esto no podría ser una opción obvia.
- Porque el mantenedor tiene su propia postura y quería explícitamente cambiar el valor predeterminado.
- No solo era la opción obvia, sino que en Debian ocurrió exactamente así: https://salsa.debian.org/debian/keepassxc/-/commit/7d6d16e3f...
  
  El post original es simplemente clickbait mal escrito.
  No se eliminó nada; solo se movió al paquete keepassxc-full.
Mientras tanto, en Arch, el paquete fwupd, que probablemente esté instalado con bastante frecuencia entre su base de usuarios, fue configurado silenciosamente para depender de passim, y passim levanta un servidor web abierto en 0.0.0.0:275001 sin consentimiento explícito del usuario.
Además, passim usa GnuTLS, famoso por tener más agujeros que un queso suizo 2.
Me parece realmente absurdo, y no me sorprendería que hubiera un exploit tipo xz escondido en algún punto de la cadena.
- Ni siquiera hace falta buscar fwupd.
  El omnipresente systemd-resolved puede abrir, bajo demanda, un servidor LLMNR en el puerto 5355; es decir, lo que también se conoce como mDNS y forma parte de la antigua familia Microsoft NetBIOS.
  En la era del Internet de las cosas, donde cualquiera puede acceder a mi LAN, ahora Linux también se está sumando a ese desastre.
  
  La corrección para fwupd es esta, ya que el archivo de configuración predeterminado es de baja calidad y ni siquiera trae valores predeterminados comentados:
```
# /etc/fwupd/fwupd.conf  
[fwupd]  
P2pPolicy=none  
```
  La corrección para resolved es poner LLMNR=no en /etc/systemd/resolved.conf, donde está comentado, y probablemente también quieras DNSStubListener=no.
  Unos valores predeterminados decentes serían estos:
```
# /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  
```
- Bueno saberlo.
  Creo que esto podría publicarse como un artículo aparte.
El responsable del paquete debería actuar según el principio de mínima sorpresa y no desactivar funciones clave salvo que exista un riesgo documentado, o al menos plausible
En esta sección de comentarios la palabra “plugin” aparece 25 veces hasta ahora, pero de lo que se habla aquí no son plugins
KeePassXC tiene muchas funciones, pero no parece haber nada que, por sí solo y sin una acción explícita del usuario, sea una fuente probable de vulnerabilidades
La integración con el navegador primero debe activarse antes de configurarla, y las demás funciones desactivadas por esta bandera probablemente sean iguales, por lo que un paquete -minimal habría sido más apropiado
La molestia grave que esto causará a quienes usaban la integración con el navegador supera por mucho a la pequeñísima cantidad de usuarios que podrían beneficiarse de este cambio en un futuro incierto
Además, la integración con el navegador suele ser una función mucho más segura que el acceso al portapapeles
Tampoco parece alinearse con la visión del proyecto:

El objetivo es crear una aplicación que cualquiera pueda usar y que también ofrezca funciones avanzadas a quienes las necesiten
Como esta distinción se podría haber creado sin romper a los usuarios existentes, es difícil verlo como otra cosa que una mala decisión del responsable del paquete de Debian
Sin duda es bueno poder usar KeepassXC sin funciones de red, pero considerar la integración con el navegador como una función de nicho está muy alejado de la realidad
Apostaría a que más de la mitad de los usuarios de KeepassXC en Debian, probablemente muchos más, quieren funciones que serán desactivadas sin aviso por la forma en que se hizo esto
Al final la decisión está en sus manos, pero eso no significa que sea una buena decisión, y yo creo que no lo es
Palabras del mantenedor de KeePassXC:

Antes de que empezara este hilo, recibimos tres reportes de que este nuevo esquema de empaquetado había arruinado el flujo de trabajo de algunas personas. Uno fue de un usuario al que se le eliminó la función de yubikey y ya no podía abrir su base de datos. Piénsenlo un momento. Alguien que pierde acceso a sus secretos más importantes puede entrar en pánico y, a veces, actuar de forma irracional

https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
- Si usas un gestor de contraseñas offline y no tienes respaldo, puedes darlo todo por perdido
  Esto suena a chantaje emocional
  Quién sabe cuántas veces se ha perdido todo por una falla de hardware, una actualización que rompió el sistema operativo, usar dd en la unidad equivocada, etc.
Si un mantenedor downstream quiere cambiar un paquete de una forma distinta a la intención del proyecto upstream, creo que debería distribuirlo con otro nombre y encargarse directamente de todos los reportes de bugs causados por esa versión modificada
- La compilación predeterminada tiene networking en OFF
  Lo mismo aplica para Yubikey, la integración con el 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...
- La opción de compilación WITH_XC_NETWORKING viene desactivada por defecto, así que está claro que los desarrolladores pretendían que esta configuración fuera una configuración de compilación válida
- Sé que normalmente esto no se cumple bien, pero el flujo predeterminado debería ser así
  Si usas un paquete proporcionado por una distribución y encuentras un bug, deberías abrir el bug contra el paquete de la distribución; luego el mantenedor lo revisa y, si es un bug que viene de upstream, lo eleva al proyecto upstream
  Este enfoque es útil porque 1. el responsable del paquete conoce el paquete y puede hacer la clasificación y el análisis iniciales, e incluso corregirlo antes de que llegue a upstream, y 2. como se dijo, los paquetes de las distribuciones a menudo incluyen parches, así que el mantenedor debe verificar si el problema está en el empaquetado o en el código fuente upstream
  Lamentablemente, muchos usuarios reportan primero a upstream
  Así que, en la práctica, es una preocupación razonable, pero en principio no debería ocurrir
- O bien habría que señalar a los usuarios finales que es un paquete no soportado
  Por ejemplo, que aparezca como KeePassXC-Debian o KeePassXC-Unsupported, y que en About se quiten los datos de contacto o el sitio web de los desarrolladores y se reemplacen por información de soporte de Debian
  Pequeños cambios downstream para adaptarse al sistema operativo están bien
  Pero modificar la app para eliminar funciones centrales y hacer que los desarrolladores upstream reciban una enorme cantidad de quejas no está bien
- No entiendo por qué comentan sin leer ni siquiera el texto enlazado de 200 caracteres
  El mantenedor activó todos los plugins, incluidos los relacionados con red, en el paquete keepassxc-full, y dejó el paquete keepassxc solo con las funciones básicas, con una postura de seguridad mucho mejor
  Esto es claramente totalmente aceptable y está dentro de las atribuciones del mantenedor
  Toda la queja es que esto es un cambio
Para quien tenga interés, este issue de GitHub parece contener los comentarios más recientes

https://github.com/keepassxreboot/keepassxc/issues/10725
- La postura de Julian Klode, mantenedor de Debian, es bastante filosa:
  
  Lamentablemente, eso no va a suceder. Haber compilado y distribuido todos los plugins por defecto fue un error. Será doloroso durante más o menos un año porque los usuarios no leen el archivo NEWS que deberían leer, pero hay muy poco que se pueda hacer.
  
  Es nuestra responsabilidad ofrecer a los usuarios, por defecto, la opción más segura posible. Todas estas funciones son innecesarias y en realidad no pertenecen a un gestor local de bases de datos de contraseñas. Toda esta dirección de desarrollo está completamente equivocada.
  
  Los usuarios que necesiten esta basura pueden instalar la versión basura, pero por supuesto eso aumenta el riesgo de un ataque de un contribuidor ocasional.
El título está mal
El texto original decía que el mantenedor había eliminado no solo las funciones de red, sino todas las funciones, y era correcto porque, en efecto, todas las funciones opcionales, incluso las completamente offline, fueron desactivadas durante la compilación