Le mainteneur Debian de KeePassXC supprime toutes les fonctionnalités réseau

 (fosstodon.org/@keepassxc)
1 points par GN⁺ 2024-05-12 | 1 commentaires | Partager sur WhatsApp
  • Si le paquet Debian keepassxc devient un paquet aux fonctionnalités minimales, les utilisateurs qui veulent conserver les fonctions actuelles devront passer à keepassxc-full
  • La suppression ne se limite pas au réseau et inclut aussi YubiKey, l’auto-type, l’intégration navigateur, l’agent SSH, les secrets FDO, le téléchargement des favicons et HIBP
  • La description du paquet Debian indique que keepassxc de base ne fournit qu’une « bare minimal functionality » et classe le réseau, l’agent SSH, le plugin navigateur et le stockage de secrets FDO comme une complexité de sécurité
  • L’annonce du changement sera transmise via NEWS.Debian.gz et apt-listchanges, et les utilisateurs de stable devront consulter les notes de version
  • Le nom du paquet et la méthode de transition peuvent encore évoluer ; après Trixie, une option où apt install keepassxc afficherait les deux choix est évoquée

Changement du paquet Debian keepassxc

  • Team KeePassXC a informé les utilisateurs Debian que le mainteneur du paquet keepassxc prévoit de supprimer une grande partie des fonctionnalités
  • Si le changement est étendu au-delà de testing/sid, les utilisateurs ayant besoin des fonctions existantes devront passer à keepassxc-full
  • Le rapport de bug Debian peut donner l’impression qu’il s’agit seulement d’une désactivation du réseau, mais Team KeePassXC rétorque que le changement réel ressemble davantage à une suppression globale de fonctionnalités au-delà du réseau

Étendue des fonctionnalités supprimées

  • Selon Team KeePassXC, les éléments suivants sont concernés
    • YubiKey
    • auto-type
    • intégration navigateur
    • agent SSH
    • secrets FDO
    • réseau
    • téléchargement des favicons
    • HIBP

Description du paquet Debian et justification

  • La description du paquet keepassxc dans Debian sid indique que le paquet de base n’inclut qu’un minimum de fonctionnalités
  • Cette description considère le réseau, l’agent SSH, le plugin navigateur et le stockage de secrets FDO comme une complexité de sécurité, et recommande d’utiliser keepassxc-full uniquement en cas de besoin
  • Le rapport de bug Debian associé partagé est #953529 - keepassxc: Compiling with disable networking support

Position du mainteneur Debian

  • Le mainteneur Debian présente /usr/share/doc/<package>/NEWS.Debian.gz comme le premier endroit où vérifier les changements inattendus
  • Les utilisateurs de testing/unstable peuvent voir automatiquement les changements si apt-listchanges est installé, tandis que les utilisateurs de stable doivent lire les notes de version
  • Il indique que cette décision a été discutée pendant un an et qu’après l’affaire xz-utils, la tendance a été de réduire autant que possible le code inclus par défaut
  • Le mainteneur estime que l’intersection entre les utilisateurs voulant à la fois Debian, KeePassXC et un gestionnaire de mots de passe très riche en fonctionnalités n’est pas si importante
  • Il affirme qu’il n’est pas logique d’introduire des « trous » dans un gestionnaire de mots de passe uniquement local

Problème de communication entre upstream et downstream

  • Un utilisateur souligne comme problème le fait que les développeurs upstream semblent totalement surpris alors que la discussion dure depuis longtemps
  • Le mainteneur Debian répond qu’il s’agit d’un sujet interne au projet Debian et qu’il a demandé l’avis d’autres développeurs Debian sur IRC
  • Il explique qu’il connaissait déjà la position d’upstream, qu’upstream a quitté IRC il y a plusieurs années et qu’il manque déjà d’énergie rien que pour empaqueter les nouvelles versions
  • Team KeePassXC et certains utilisateurs craignent que cette décision downstream n’entraîne un afflux de rapports de bug et de confusion côté upstream

Nom du paquet et orientation de la transition

  • Plusieurs utilisateurs suggèrent qu’au lieu de transformer keepassxc en paquet minimal, il serait moins confus d’utiliser un nom comme keepassxc-minimal ou keepassxc-light, tout en conservant keepassxc actuel avec toutes les fonctionnalités
  • Une proposition était la suivante
    • keepassxc-light
    • keepassxc-full
    • keepassxc dépendrait de keepassxc-full comme paquet de transition
    • explication du changement dans NEWS.Debian
  • Le mainteneur Debian répond que le changement de nom dépend de l’approbation du ftpteam, et que l’orientation avec paquet de transition pour Trixie pourrait être la meilleure proposition
  • Après Trixie, il est aussi envisagé de supprimer le paquet de transition et de faire en sorte que apt install keepassxc affiche les deux choix

À lire aussi

1 commentaires

 
GN⁺ 2024-05-12
Avis de Hacker News

  • Distribuer sous le même nom un logiciel après avoir retiré en masse des fonctionnalités que l’upstream y avait intégrées me paraît suspect, même avec bienveillance.
    Si l’on veut aller dans cette direction, il faut le distribuer comme un fork sous un autre nom, afin que l’upstream ne continue pas à être harcelé par des signalements de problèmes utilisateurs.
    Ça me rappelle l’époque où le mainteneur Debian de Chromium avait désactivé unilatéralement l’installation d’extensions, avant que le patch ne soit finalement annulé.
    Je pense aussi à un épisode bien plus ancien où Debian avait supprimé l’interface du noyau permettant de charger un firmware binaire pour les cartes réseau, ce qui avait cassé mon réseau.

    • En réalité, tout ce qui a été fait, c’est passer le paramètre de build XC_ALL à OFF [0], et cette valeur est aussi la valeur par défaut dans le CMakeLists.txt de l’upstream [1].
      Si l’upstream estime que cette fonctionnalité est si importante, il devrait commencer par corriger la valeur par défaut.
      On peut comprendre que des utilisateurs soient déroutés si la fonctionnalité cesse de marcher après une mise à niveau, mais le fait que le paquet sans suffixe corresponde aux valeurs par défaut de l’upstream est, en soi, assez raisonnable.

      [0] https://salsa.debian.org/debian/keepassxc/-/commit/7d6d16e3f...
      [1] https://github.com/keepassxreboot/keepassxc/blob/develop/CMa...

    • Le rôle d’un mainteneur ne se limite pas à copier-coller l’upstream.
      Il a le droit de juger ce qui est approprié pour les utilisateurs finaux de la distribution.
      Dans ce cas, il semble y avoir une justification de sécurité raisonnable, et un paquet alternatif est aussi fourni.

    • Debian semble être la seule distribution à avoir cette attitude étrange consistant à ignorer l’upstream.
      Sur deux projets upstream que je maintiens, Debian a aussi renommé unilatéralement les paquets.
      Pour l’un, je ne l’ai découvert que bien plus tard ; pour l’autre, cela a été fait d’une manière totalement absurde alors même que je m’y étais explicitement opposé.
      Au final, c’est moi qui dois l’expliquer aux utilisateurs.

      Modification : on peut voir ici l’arrogance de Julian côté Debian : https://github.com/keepassxreboot/keepassxc/issues/10725#iss... — c’est exactement ce dont je parle.

    • Ils n’ont pas « charcuté » ce qu’a fait l’upstream.
      Ils distribuent une version sans plugins, et ont créé une version -full qui inclut les plugins.
      Si le plugin est activé par défaut, alors ce n’est pas un plugin mais une fonctionnalité intégrée, et cette approche est la bonne.

    • Si Apple disait « nous avons modifié votre application parce que nous pensons que c’est mieux pour la sécurité », les gens sortiraient les torches et les fourches.
      Mais quand c’est un mainteneur deb qui le fait, cela devient matière à débat.
      S’il y a un problème de sécurité, la version non sûre ne devrait tout simplement pas être proposée ; or ici, ce n’est même pas le cas.
      Dans un monde façon App Store, le rôle du mainteneur doit changer.
      Son travail est de faire en sorte que le logiciel fonctionne dans la distribution, pas de créer un quasi-fork selon ses préférences tout en gardant le même nom.

  • Cela semble être une décision assez raisonnable.
    Les fonctionnalités réseau et l’intégration au navigateur sont de grosses failles potentielles et des points d’entrée pour les attaques.
    Si l’on exécute uniquement une base de données de confiance, sans fonctionnalités liées au réseau, alors même si une vulnérabilité est découverte, il devrait être presque impossible d’exploiter l’outil ; c’est une propriété très souhaitable pour un outil aussi critique qu’un gestionnaire de mots de passe.
    Le mainteneur initial est d’ailleurs d’accord [1].
    Le paquet complet avec le réseau activé existe aussi dans Debian ; les utilisateurs qui le veulent n’ont qu’à faire apt install keepassxc-full pour disposer de toutes les fonctionnalités réseau.
    Cela dit, qualifier l’upstream de “crappy”[0] n’est pas une attitude productive pour un mainteneur de paquet, et les noms de paquets keepassxc et keepassxc-full auraient sans doute été moins clairs pour les utilisateurs Debian que keepassxc-lite et keepassxc-full.

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

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

    • Beaucoup de choses sont de grosses failles potentielles et des points d’entrée pour les attaques, tout en étant utiles.
      « Utile » peut renforcer la sécurité.
      Si un gestionnaire de mots de passe est difficile à utiliser, les gens cessent de s’en servir.
      En y regardant de plus près, il n’est pas évident que l’usage du presse-papiers soit forcément plus sûr que l’intégration au navigateur.
      De simples erreurs de copier-coller peuvent à elles seules compenser une bonne partie de la charge de sécurité liée à l’intégration au navigateur.
      Il y a longtemps, j’ai travaillé en mission pour une grande entreprise : les ordinateurs portables des account managers avaient un mot de passe de chiffrement du disque, un mot de passe de connexion Windows et un mot de passe de connexion AD ; ils devaient tous être différents, être changés tous les quelques mois, et respecter des exigences de complexité sévères.
      Tous les portables que j’ai vus, sans exception, avaient un post-it avec les trois mots de passe écrits dessus.
      Le point essentiel, c’est que la sécurité fantasmée de passionné de sécurité n’est pas la même chose que la sécurité réelle sur le terrain.
      Du moins, pas toujours, et il faut ici faire de vrais compromis.

[1] : Nous intervenions comme prestataires externes pour assurer la maintenance des ordinateurs portables de certains employés
Normalement, cela n’aurait pas dû se faire, mais passer par le système IT de l’entreprise prenait beaucoup trop de temps à cause de la bureaucratie ; c’était bien plus rapide et plus simple ainsi
C’était ce genre d’entreprise
En soi, c’était évidemment aussi un « risque de sécurité », car il n’est pas normal qu’un technicien quelconque d’un magasin d’informatique manipule un ordinateur portable contenant des données d’entreprise ultraconfidentielles
Cela dit, je pense qu’il n’y avait pas tant de choses que ça à protéger. Il s’agissait surtout de chiffres de ventes/de clients, des informations utiles seulement à un nombre très limité de personnes

  • L’intégration au navigateur améliore la sécurité sur un point par rapport au copier-coller manuel
    L’extension de navigateur vérifie l’URL de la page avant de remplir les identifiants, alors que le copier-coller manuel est vulnérable aux domaines avec faute de frappe et au phishing par caractères homoglyphes

  • Je suis d’accord pour dire que les fonctions réseau et l’intégration au navigateur constituent de grosses failles potentielles, mais, comme l’ont dit les participants à l’issue GitHub, il est important de noter que les builds réduits sont très peu testés par rapport au build complet, et que les combinaisons arbitraires de flags de build ne sont pas testées du tout
    Comme cela a été mentionné ailleurs, l’un des flags « optionnels » désactivés est la prise en charge de YubiKey, ce qui fait que des utilisateurs ayant mis à niveau vers le nouveau paquet cassé se retrouvent verrouillés hors de leur gestionnaire de mots de passe
    Réactiver seulement ce flag revient déjà à se retrouver dans un état que, concrètement, personne ne teste
    Si l’on part du principe que les utilisateurs existants ont été migrés vers keepassxc-full, je suis d’accord que le nom keepassxc-lite aurait évité le problème
    Mais c’est précisément le point central
    Il est raisonnable de faire de la solution la plus sûre le choix par défaut, mais le mainteneur ne devrait pas casser des fonctionnalités existantes si l’upstream ou les utilisateurs ne le souhaitent pas, et surtout pas enfermer des utilisateurs hors de leur gestionnaire de mots de passe

  • Publier « crappy » sur GitHub était tellement impoli que, si j’avais utilisé Debian, j’aurais reconsidéré son utilisation
    Si le paquet est rempli de fonctionnalités aussi médiocres, je ne vois pas pourquoi se donner la peine de le maintenir
    Autant le supprimer et laisser les utilisateurs trouver eux-mêmes comment l’installer correctement
    Je plains les développeurs de KeepassXC : maintenir un projet open source est déjà difficile, et ils doivent en plus gérer ce genre de choses

  • À l’instant où j’ai vu l’expression crappy, tout respect pour julian-klode a disparu

  • La solution proposée par drawks semble clairement être le bon choix :

    La solution appropriée consisterait probablement à empaqueter à la fois une version « -full » et une version « -minimal » du logiciel, à définir dans les métadonnées des paquets Debian une relation Conflicts entre les deux paquets, à les marquer tous les deux comme fournissant keepassxc via Provides, et à ajouter aussi un tag Replaces: keepassxc au build -full. Ainsi, lors d’une mise à niveau, les utilisateurs existants recevraient la version qui continue de fournir les fonctionnalités du paquet mis à niveau/remplacé, tandis que les nouveaux utilisateurs pourraient choisir eux-mêmes la version à installer

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

    Je ne vois pas pourquoi cela ne serait pas l’option évidente

    • Parce que le mainteneur a son propre point de vue et voulait explicitement changer le comportement par défaut

    • Non seulement c’est le choix évident, mais c’est aussi exactement ce qui s’est passé dans Debian : https://salsa.debian.org/debian/keepassxc/-/commit/7d6d16e3f...

      Le billet original est simplement du clickbait mal écrit
      Rien n’a été supprimé, cela a seulement été déplacé dans le paquet keepassxc-full

  • Pendant ce temps, du côté d’Arch, le paquet fwupd, probablement assez couramment installé dans sa base d’utilisateurs, a été configuré discrètement pour dépendre de passim, et passim lance un serveur web ouvert sur 0.0.0.0:27500[1] sans consentement explicite de l’utilisateur
    En plus, passim utilise GnuTLS, connu pour avoir plus de trous que du gruyère [2][3]
    Je trouve ça absolument absurde, et je ne serais pas surpris qu’un exploit du type xz se cache quelque part dans la chaîne

    [1] : https://github.com/fwupd/fwupd/issues/6721

    [2] : https://news.ycombinator.com/item?id=7347500

    [3] : https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=gnutls

    • Pas besoin de chercher du côté de fwupd
      systemd-resolved, présent partout, peut ouvrir à la demande un serveur LLMNR sur le port 5355, autrement dit ce qu’on appelle aussi mDNS et qui appartient à l’ancienne famille Microsoft NetBIOS
      À cause de l’Internet des objets, à l’heure où tout le monde peut accéder à mon LAN, on est en train de faire entrer Linux dans ce bazar

      Pour corriger fwupd, comme le fichier de configuration par défaut est de mauvaise qualité et ne contient même pas de valeurs par défaut commentées, on peut faire ceci :

      # /etc/fwupd/fwupd.conf  
[fwupd]  
P2pPolicy=none

      Pour corriger resolved, LLMNR=no est commenté dans /etc/systemd/resolved.conf, et vous voudrez probablement aussi DNSStubListener=no
      De bons paramètres par défaut ressemblent à ceci :

      # /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

    • Bon à savoir
      Ça mériterait presque un article à part

  • J’estime qu’un mainteneur de paquet doit agir selon le principe de moindre surprise, et ne pas désactiver de fonctionnalités essentielles sauf s’il existe un risque documenté, ou au minimum plausible.
    Le mot « plugin » apparaît actuellement 25 fois dans cette section de commentaires, mais ce dont il est question ici n’est pas un plugin.
    KeePassXC a beaucoup de fonctionnalités, mais aucune ne semble être, à elle seule et sans action explicite de l’utilisateur, une source vraisemblable de vulnérabilités.
    L’intégration au navigateur doit d’abord être activée avant d’être configurée, et les autres fonctionnalités désactivées par ce drapeau sont sans doute dans le même cas ; un paquet -minimal aurait donc été plus approprié.
    La gêne importante causée aux personnes qui utilisaient l’intégration au navigateur dépasse de très loin le bénéfice qu’en tirera un nombre infime d’utilisateurs dans un avenir incertain.
    L’intégration au navigateur est aussi, en général, une fonctionnalité bien plus sûre que l’accès au presse-papiers.
    Cela ne semble pas non plus correspondre à la vision du projet :

    L’objectif est de créer une application utilisable par tous, tout en offrant des fonctionnalités avancées à ceux qui en ont besoin.

  • Comme il était possible d’établir cette distinction sans casser l’expérience des utilisateurs existants, il est difficile d’y voir autre chose qu’une mauvaise décision du mainteneur Debian.
    Il est évidemment positif de pouvoir utiliser KeepassXC sans fonctionnalités réseau, mais considérer l’intégration au navigateur comme une fonctionnalité de niche est complètement déconnecté de la réalité.
    Je parierais que plus de la moitié des utilisateurs de KeepassXC sous Debian, probablement bien davantage, veulent des fonctionnalités qui vont être désactivées sans préavis avec cette approche.
    Au final, la décision leur appartient, mais cela ne veut pas dire qu’elle est bonne ; à mon avis, elle ne l’est pas.

  • D’après le mainteneur de KeePassXC :

    Avant le début de ce fil, nous avions reçu trois signalements indiquant que cette nouvelle méthode de packaging avait cassé le workflow de certaines personnes. L’un d’eux concernait un utilisateur chez qui la fonctionnalité yubikey avait été supprimée, l’empêchant désormais d’ouvrir sa base de données. Prenez un instant pour y réfléchir. Quelqu’un qui n’a plus accès à ses secrets les plus importants peut paniquer et agir parfois de manière irrationnelle.

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

    • Si vous utilisez un gestionnaire de mots de passe hors ligne et que vous n’avez pas de sauvegarde, vous pouvez considérer que vous avez déjà tout perdu.
      Ça ressemble à du chantage émotionnel.
      Je ne sais même plus combien de fois des gens ont tout perdu à cause d’une panne matérielle, d’une mise à jour qui a cassé le système d’exploitation, d’un dd lancé sur le mauvais disque, etc.

  • Si un mainteneur downstream veut modifier un paquet d’une manière contraire à l’intention du projet upstream, il devrait le distribuer sous un autre nom et traiter lui-même tous les rapports de bugs causés par cette version modifiée.

    • Le build par défaut a le réseau désactivé.
      Il en va de même pour Yubikey, l’intégration au navigateur, etc.

      -DWITH_XC_NETWORKING=[ON|OFF] Enable/Disable Networking support (e.g., favicon downloading) (default: OFF)

      https://github.com/keepassxreboot/keepassxc/blob/develop/INS...

    • L’option de build WITH_XC_NETWORKING étant désactivée par défaut, il est clair que les développeurs considéraient cette configuration comme un réglage de build valide.

    • Je sais bien que ce n’est généralement pas respecté, mais c’est le flux normal prévu.
      Si l’on utilise un paquet fourni par une distribution et que l’on rencontre un bug, on devrait ouvrir un bug sur le paquet de la distribution ; le mainteneur l’examine, puis, si le bug vient de l’upstream, il le transmet au projet upstream.
      Cette approche est utile parce que 1. le mainteneur du paquet connaît le paquet et peut faire un premier tri et une première analyse, voire corriger directement le problème avant qu’il n’arrive upstream, et 2. comme dit plus haut, les paquets des distributions incluent souvent des patchs, donc le mainteneur doit vérifier si le problème vient du packaging ou du code source upstream.
      Malheureusement, beaucoup d’utilisateurs signalent d’abord les problèmes upstream.
      Donc, en pratique, c’est une inquiétude compréhensible, mais en principe, cela ne devrait pas se passer ainsi.

    • Ou alors il faut indiquer à l’utilisateur final qu’il s’agit d’un paquet non pris en charge.
      Par exemple, le présenter comme KeePassXC-Debian ou KeePassXC-Unsupported, et remplacer dans la fenêtre About les contacts ou le site web des développeurs par les informations de support Debian.
      De petites modifications downstream pour l’adapter au système d’exploitation sont acceptables.
      Mais modifier l’application pour supprimer des fonctionnalités essentielles et faire retomber une énorme quantité de plaintes sur les développeurs upstream ne l’est pas.

    • Je ne comprends pas pourquoi vous commentez sans même lire le billet de 200 caractères lié.
      Le mainteneur a activé dans le paquet keepassxc-full tous les plugins, y compris ceux liés au réseau, tandis que le paquet keepassxc ne contient plus que les fonctionnalités de base avec une bien meilleure posture de sécurité.
      C’est clairement tout à fait acceptable et dans le périmètre d’autorité du mainteneur.
      Toute la plainte tient au fait qu’il s’agit d’un changement.

  • Pour ceux que cela intéresse, cette issue GitHub semble contenir les commentaires les plus récents.

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

    • La position de Julian Klode, mainteneur Debian, est assez tranchante :

      Désolé, mais cela n’arrivera pas. Construire et distribuer par défaut tous les plugins était une erreur. Ce sera pénible pendant environ un an, parce que les utilisateurs refusent obstinément de lire le fichier NEWS qu’ils devraient lire, mais il n’y a pas grand-chose à y faire.

      Il est de notre responsabilité de fournir par défaut l’option la plus sûre possible aux utilisateurs. Toutes ces fonctionnalités sont inutiles et n’ont pas vraiment leur place dans un gestionnaire local de base de données de mots de passe. Toute cette orientation de développement est complètement erronée.

      Les utilisateurs qui ont besoin de cette merde peuvent installer la version merdique, mais cela augmente évidemment le risque d’attaque par contributeur de passage.

  • Le titre est faux.
    L’article d’origine disait que le mainteneur avait supprimé non seulement les fonctionnalités réseau, mais toutes les fonctionnalités, et c’était exact, puisque toutes les fonctionnalités optionnelles, y compris celles entièrement hors ligne, ont effectivement été désactivées au moment du build.