Les développeurs de GPG ont d'ailleurs "clarifié" leur documentation depuis.
Personnellement, je trouve que ce n'est pas une simple "clarification", mais plutôt une correction de la documentation. La documentation passe quand même de "Ce statut indique que la signature est valide." à "Ce statut indique que la signature peut être vérifiée ou est vide".
Je sais pas si c’est moi qui vieilli ou si ça a toujours été comme ça, mais j’ai l’impression que les développeurs/promoteurs de GPG jouent de plus en plus à l’autruche.
Si une entreprise avait communiquée comme ils l’ont fait ces derniers temps on l’aurait largement critiqué.
Pour les soucis de gestion des signatures dans SKS (et dans GPG dont la BDD ne supporte pas quelques milliers d’entrées), ils ont quand même dit en substance « on le savait depuis des années, tout ça c’est de la faute des personnes qui ont exploités la faille ».
Full disclosure : Je suis un contributeur occasionnel de GnuPG, mainteneur de Scute (l’interface PKCS#11 pour les cartes OpenPGP), membre du GnuPG e.V. (une association allemande de personnes impliquées dans OpenPGP — pas seulement GnuPG contrairement à ce que le nom peut laisser croire), et animateur régulier d’ateliers consacrés entre autres au chiffrement d’e-mails au sein des cryptoparties londoniennes. Avec cet éclairage, interprétez le commentaire ci-dessous comme vous voudrez. Il va sans dire que ce message n’engage que moi et aucunement lesautres contributeurs à GnuPG.
Si une entreprise avait communiquée comme ils l’ont fait ces derniers temps on l’aurait largement critiqué.
Parce que les développeurs de GnuPG ne sont pas critiqués peut-être ? Ils s’en prennent plein la gueule, oui, et pas seulement depuis « ces derniers temps ».
En raison vraisemblablement de son statut « d’implémentation libre de référence » d’OpenPGP (qui au passage entraîne l’éternelle confusion entre OpenPGP, PGP, GPG, que j’essaye régulièrement de dissiper chaque fois que j’en ai l’occasion tellement elle fait du tort à tout le monde), le moindre problème dans l’écosystème est mis sur le dos de GnuPG.
Le fonctionnement des serveurs de clefs en mode append-only, qui les rend vulnérables aux empoisonnements ? « C’est de la faute de GnuPG, ses développeurs étaient au courant mais ils n’ont rien fait. » Alors que ① aucun développeur de GnuPG n’est impliqué dans les logiciels serveurs de clefs, et ② GnuPG propose depuis plusieurs années maintenant une méthode alternative de distribution des celfs précisément dans le but de se passer du réseau des serveurs HKP et leurs problèmes inhérents.
La complexité de la toile de confiance, qui est imbitable pour tout le monde ? C’est GnuPG bien sûr. Alors que ① le concept de la toile de confiance a été inventé par Phil Zimmerman dès 1995, au moins deux ans avant que le première ligne de code de GnuPG ne soit écrite, et ② GnuPG est à ce jour la seule implémentation d’OpenPGP à avoir proposé de dépasser le modèle de la toile de confiance pour le remplacer par un modèle à la fois plus simple et plus en accord avec les pratiques réelles des utilisateurs (trust-on-first-use).
La faille E-FAIL ? Le papier décrivant l’attaque mentionnait clairement que, parmi tous les clients e-mail testés, seuls Thunderbird (avec le plugin Enigmail) et Outlook (avec le plugin GpgOL) étaient vulnérables. Tous les autres (Claws-Mail, KMail, Mutt, Evolution…) déjouaient l’attaque. Ça indique bien que le problème venait des clients mails plutôt que de GnuPG lui-même (sinon tous les clients utilisant GnuPG en arrière-plan auraient été vulnérables), mais non, « c’est de la faute de GnuPG. Et en plus ils n’assument pas, regardez quand on tente de leur faire remarquer ils se défaussent sur le code des autres ».
Je ne m’attarderai pas sur les attaques de certains universitaires à la Matthew Green, qui font preuve d’une mauvaise foi rarement égalée. (J’ai particulièrement aimé la fois où Matthew Green a déclaré qu’il s’amusait à faire lire le code de GnuPG à ses étudiants, qui après une semaine revenaient le supplier de ne plus jamais les soumettre à une torture pareille tellement le code serait imbitable. Que le code de GnuPG soit critiquable, je veux bien — montrez-moi du code vieux de vingt ans qui ne le soit pas —, mais de là à dire qu’il est illisible, je m’insurge. Pour ce que ça vaut, quand je me suis penché pour la première fois sur le code de GnuPG il y a six ans, j’ai au contraire trouvé qu’il était assez facile de s’y retrouver — c’est bien d’ailleurs ce qui m’a permis de soumettre mon premier patch, alors que je ne suis même pas développeur ; serais-je plus doué que les étudiants du Professeur Green ?).
Je ne prétends pas que GnuPG est parfait. Certaines critiques à son encontre sont parfaitement justifiées et oui, il y a des bugs. C’est un fait, par exemple, que l’empoisonnement des serveurs SKS aurait été beaucoup moins grave s’il n’avait pas été accompagné d’une conception critiquable de la gestion des trousseaux de clefs dans GnuPG¹.
Mais face aux critiques débordantes de mauvaise foi et/ou visant GnuPG alors que ce sont d’autres composantes de l’écosystème OpenPGP qui sont concernés, face aux GnuPG haters qui ont du mal à cacher leur jubilation à chaque annonce d’un nouvelle faille (peu importe que la faille touche réellement GnuPG ou pas), face à tous ceux qui réclament à cors et à cri la mort de GnuPG et disent à tout le monde d’utiliser Signal (peu importe que Signal et GnuPG ne remplissent pas du tout la même fonction et n’offrent pas du tout les mêmes garanties)… ben je ne jetterai pas la pierre aux développeurs de GnuPG d’ignorer royalement ces gens-là.
Merde. Si vous avez un problème avec GnuPG, il y a d’autres implémentations. Aucune n’a toutes les fonctionnalités de GnuPG, mais certaines sont prometteuses.
¹ En gros, l’insertion d’une nouvelle clef dans le trousseau était une opération dont la complexité variait avec le carré du nombre de signatures portées par la clef, ce qui rendait très facile de faire un déni de service. Quelques milliers de signatures sur une clef suffisaient à mettre GnuPG à genou, là où d’autres implémentations ne rencontraient aucune difficulté. (Le problème a été corrigé depuis.)
# GPG
Posté par Anonyme . Évalué à 2.
Je trouve très intéressant le commentaire de sqrt7 sur Reddit.
[^] # Re: GPG
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 4.
Les développeurs de GPG ont d'ailleurs "clarifié" leur documentation depuis.
Personnellement, je trouve que ce n'est pas une simple "clarification", mais plutôt une correction de la documentation. La documentation passe quand même de "Ce statut indique que la signature est valide." à "Ce statut indique que la signature peut être vérifiée ou est vide".
[^] # Re: GPG
Posté par Anonyme . Évalué à 3.
Je sais pas si c’est moi qui vieilli ou si ça a toujours été comme ça, mais j’ai l’impression que les développeurs/promoteurs de GPG jouent de plus en plus à l’autruche.
Si une entreprise avait communiquée comme ils l’ont fait ces derniers temps on l’aurait largement critiqué.
Pour les soucis de gestion des signatures dans SKS (et dans GPG dont la BDD ne supporte pas quelques milliers d’entrées), ils ont quand même dit en substance « on le savait depuis des années, tout ça c’est de la faute des personnes qui ont exploités la faille ».
[^] # Re: GPG
Posté par gouttegd (site web personnel) . Évalué à 10.
Full disclosure : Je suis un contributeur occasionnel de GnuPG, mainteneur de Scute (l’interface PKCS#11 pour les cartes OpenPGP), membre du GnuPG e.V. (une association allemande de personnes impliquées dans OpenPGP — pas seulement GnuPG contrairement à ce que le nom peut laisser croire), et animateur régulier d’ateliers consacrés entre autres au chiffrement d’e-mails au sein des cryptoparties londoniennes. Avec cet éclairage, interprétez le commentaire ci-dessous comme vous voudrez. Il va sans dire que ce message n’engage que moi et aucunement lesautres contributeurs à GnuPG.
Parce que les développeurs de GnuPG ne sont pas critiqués peut-être ? Ils s’en prennent plein la gueule, oui, et pas seulement depuis « ces derniers temps ».
En raison vraisemblablement de son statut « d’implémentation libre de référence » d’OpenPGP (qui au passage entraîne l’éternelle confusion entre OpenPGP, PGP, GPG, que j’essaye régulièrement de dissiper chaque fois que j’en ai l’occasion tellement elle fait du tort à tout le monde), le moindre problème dans l’écosystème est mis sur le dos de GnuPG.
Le fonctionnement des serveurs de clefs en mode append-only, qui les rend vulnérables aux empoisonnements ? « C’est de la faute de GnuPG, ses développeurs étaient au courant mais ils n’ont rien fait. » Alors que ① aucun développeur de GnuPG n’est impliqué dans les logiciels serveurs de clefs, et ② GnuPG propose depuis plusieurs années maintenant une méthode alternative de distribution des celfs précisément dans le but de se passer du réseau des serveurs HKP et leurs problèmes inhérents.
La complexité de la toile de confiance, qui est imbitable pour tout le monde ? C’est GnuPG bien sûr. Alors que ① le concept de la toile de confiance a été inventé par Phil Zimmerman dès 1995, au moins deux ans avant que le première ligne de code de GnuPG ne soit écrite, et ② GnuPG est à ce jour la seule implémentation d’OpenPGP à avoir proposé de dépasser le modèle de la toile de confiance pour le remplacer par un modèle à la fois plus simple et plus en accord avec les pratiques réelles des utilisateurs (trust-on-first-use).
La faille E-FAIL ? Le papier décrivant l’attaque mentionnait clairement que, parmi tous les clients e-mail testés, seuls Thunderbird (avec le plugin Enigmail) et Outlook (avec le plugin GpgOL) étaient vulnérables. Tous les autres (Claws-Mail, KMail, Mutt, Evolution…) déjouaient l’attaque. Ça indique bien que le problème venait des clients mails plutôt que de GnuPG lui-même (sinon tous les clients utilisant GnuPG en arrière-plan auraient été vulnérables), mais non, « c’est de la faute de GnuPG. Et en plus ils n’assument pas, regardez quand on tente de leur faire remarquer ils se défaussent sur le code des autres ».
Je ne m’attarderai pas sur les attaques de certains universitaires à la Matthew Green, qui font preuve d’une mauvaise foi rarement égalée. (J’ai particulièrement aimé la fois où Matthew Green a déclaré qu’il s’amusait à faire lire le code de GnuPG à ses étudiants, qui après une semaine revenaient le supplier de ne plus jamais les soumettre à une torture pareille tellement le code serait imbitable. Que le code de GnuPG soit critiquable, je veux bien — montrez-moi du code vieux de vingt ans qui ne le soit pas —, mais de là à dire qu’il est illisible, je m’insurge. Pour ce que ça vaut, quand je me suis penché pour la première fois sur le code de GnuPG il y a six ans, j’ai au contraire trouvé qu’il était assez facile de s’y retrouver — c’est bien d’ailleurs ce qui m’a permis de soumettre mon premier patch, alors que je ne suis même pas développeur ; serais-je plus doué que les étudiants du Professeur Green ?).
Je ne prétends pas que GnuPG est parfait. Certaines critiques à son encontre sont parfaitement justifiées et oui, il y a des bugs. C’est un fait, par exemple, que l’empoisonnement des serveurs SKS aurait été beaucoup moins grave s’il n’avait pas été accompagné d’une conception critiquable de la gestion des trousseaux de clefs dans GnuPG¹.
Mais face aux critiques débordantes de mauvaise foi et/ou visant GnuPG alors que ce sont d’autres composantes de l’écosystème OpenPGP qui sont concernés, face aux GnuPG haters qui ont du mal à cacher leur jubilation à chaque annonce d’un nouvelle faille (peu importe que la faille touche réellement GnuPG ou pas), face à tous ceux qui réclament à cors et à cri la mort de GnuPG et disent à tout le monde d’utiliser Signal (peu importe que Signal et GnuPG ne remplissent pas du tout la même fonction et n’offrent pas du tout les mêmes garanties)… ben je ne jetterai pas la pierre aux développeurs de GnuPG d’ignorer royalement ces gens-là.
Merde. Si vous avez un problème avec GnuPG, il y a d’autres implémentations. Aucune n’a toutes les fonctionnalités de GnuPG, mais certaines sont prometteuses.
¹ En gros, l’insertion d’une nouvelle clef dans le trousseau était une opération dont la complexité variait avec le carré du nombre de signatures portées par la clef, ce qui rendait très facile de faire un déni de service. Quelques milliers de signatures sur une clef suffisaient à mettre GnuPG à genou, là où d’autres implémentations ne rencontraient aucune difficulté. (Le problème a été corrigé depuis.)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.