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

Controversia por la eliminación de funciones en el paquete KeePassXC de Debian

  • El mantenedor del paquete KeePassXC en Debian decidió de forma unilateral eliminar todas las funciones del paquete.
  • En Debian sid, el paquete keepassxc predeterminado pasará a incluir solo funciones mínimas, eliminando características como redes, agente SSH, plugin del navegador y almacenamiento de secretos FDO.
  • Si se necesitan esas funciones, habrá que cambiar al paquete keepassxc-full.

Controversia sobre las razones para eliminar funciones

  • En el reporte de errores de Debian se menciona la seguridad como motivo.
  • Sin embargo, el equipo de KeePassXC considera que eliminar no solo la conectividad de red sino también soporte para Yubikey, autocompletado por escritura automática e integración con el navegador, entre casi todas las funciones, es excesivo.
  • También existe la opinión de que eliminar funciones no reduce tanto las vulnerabilidades como sí elimina capacidades que los usuarios necesitan.

Postura y reacción de Debian

  • En Debian sostienen que eliminar código no usado y funciones innecesarias es la mejor opción para la seguridad tras el incidente de compromiso de liblzma.
  • Pero se les critica por haber tomado la decisión de manera unilateral sin coordinación previa con el equipo de KeePassXC.
  • Para minimizar la confusión de los usuarios, decidieron ofrecer un paquete transicional que convierta keepassxc en keepassxc-full.

Opinión de GN⁺

  • Eliminar funciones innecesarias por seguridad no es malo en sí, pero no es una buena forma hacerlo quitando de repente funciones que los usuarios existentes ya utilizaban sin cambiar el nombre del paquete.
  • Cuando una distribución como Debian cambia su política de paquetes, debería coordinarse en lo posible con los desarrolladores upstream y procurar minimizar la confusión desde la perspectiva del usuario.
  • Lo deseable es ofrecer por separado un paquete con todas las funciones y otro mínimo, diferenciando bien los nombres y permitiendo que el usuario elija.
  • Buscar otro gestor de contraseñas también puede ser una opción, pero también es importante contribuir y cooperar más activamente con KeePassXC para intentar mejorar el problema.
  • Que sea software libre no significa que el mantenedor del paquete pueda hacer lo que quiera; más bien debería esforzarse por respetar la opinión de usuarios y de la comunidad de desarrolladores, y por comunicarse con transparencia.

1 comentarios

 
GN⁺ 2024-05-12
Opiniones en Hacker News

Resumen de comentarios de Hacker News

1. Preocupación por eliminar funciones del proyecto upstream y distribuirlo con el mismo nombre

  • Quitar funciones implementadas por el proyecto upstream y distribuirlo con el mismo nombre puede ser problemático
  • Si se va a tomar esa dirección, debería hacerse un fork y distribuirse con otro nombre
  • Se menciona el caso pasado en el que el mantenedor del paquete Chromium de Debian deshabilitó arbitrariamente la instalación de extensiones

2. Opinión de que, desde la perspectiva de seguridad, quitar las funciones de red es razonable

  • En un gestor de contraseñas, las funciones de red y la integración con el navegador pueden convertirse en vulnerabilidades potenciales
  • Si se usa solo una base de datos confiable y sin funciones relacionadas con red, incluso si se descubre una vulnerabilidad no sería posible explotarla
  • También existe en Debian un paquete con la versión completa que incluye funciones de red, por lo que quien lo desee puede instalar keepassxc-full
  • Aun así, llamar al upstream "pésimo" no es productivo, y keepassxc-lite y keepassxc-full podrían ser nombres de paquete más apropiados

3. Se plantea que empaquetar tanto la versión "full" como la "minimal" sería la decisión correcta

  • Debería definirse una relación de Conflicts entre ambas versiones y aprovechar las etiquetas Provides y Replaces para que el usuario pueda elegir
  • Se cuestiona por qué esa no fue la elección obvia

4. Se señala el problema de hacer que en Arch Linux se dependa del paquete passim sin consentimiento del usuario

  • El paquete fwupd está configurado para depender de passim sin el consentimiento del usuario
  • passim ejecuta un servidor web en 0.0.0.0:27500 y usa GnuTLS, que tiene muchas vulnerabilidades
  • Esta configuración podría ser explotada, lo que genera preocupación

5. Opinión de que, según el principio de mínima sorpresa, no deberían deshabilitarse funciones clave salvo que exista un riesgo documentado

  • Las funciones de KeePassXC no se convierten en fuente de vulnerabilidades sin intervención explícita del usuario
  • La integración con el navegador es mucho más segura que el acceso al portapapeles y además no encaja con la visión del proyecto
  • Son muy pocos los usuarios que se beneficiarían de este cambio, mientras que causa un inconveniente grave para quienes usan la integración con el navegador

6. Se argumenta que fue una mala decisión del mantenedor de Debian, ya que era posible diferenciarlo sin romper a los usuarios existentes

  • Ofrecer una versión de KeePassXC sin funciones de red está bien, pero considerar la integración con el navegador como una función de nicho es una visión desconectada de la realidad
  • Más de la mitad de los usuarios de KeePassXC en Debian probablemente se sorprenderán por esta decisión
  • En última instancia es decisión del mantenedor del paquete, pero no fue una buena decisión

7. Cita de la opinión de un mantenedor de KeePassXC

  • Se recibieron reportes de que el nuevo método de empaquetado arruinó el flujo de trabajo de varias personas
  • Incluso hubo un caso en el que a un usuario se le eliminó la función de Yubikey y ya no pudo acceder a su base de datos
  • Las personas que pierden acceso a sus secretos más importantes pueden actuar de forma irracional en un momento de pánico

8. Opinión de que, si se modifica el paquete de forma distinta a la intención del proyecto upstream, debe distribuirse con otro nombre

  • Si un mantenedor downstream modifica el paquete, debe distribuirlo con otro nombre y hacerse cargo de todos los reportes de errores causados por esa versión modificada

9. Indicación de que la discusión más reciente puede consultarse en un issue de GitHub

10. Señalamiento de que el título es incorrecto

  • La publicación original mencionaba que no solo se eliminaron las funciones de red, sino todas las funciones, y eso es cierto
  • Durante la compilación se configuró la desactivación de todas las funciones opcionales, incluidas las funciones offline