🚲 Tanguy Ortolo a écrit 12091 commentaires

Un tissu d'âneries, non. En revanche le titre est excessif, clairement : “why the web of trust is not perfect” serait plus pertinent. Voire même “why the web of trust is not perfect, even though we found nothing better”.

Les message est composé de trois points numérotés présentant trois arguments complétement différents. Il me semble que tu ne réponds que au point numéro 2.

Oui, en effet.

Il suppose que GnuPG accorde automatiquement une confiance entière à toutes les clefs identifiées comme valides, ou à la rigueur à toutes les clefs signées avec une indication de signature complète

Non, je ne crois pas qu'il suppose ça.

Si :

Edward's GPG client has trust in a couple keys. It turns out that one of
his trusted keys, Bruce, has full trust in Roger's key (the compromised
key).

Edward's GPG client then computes a fully trusted path from Bruce to
Roger to the fake Glenn, and Edward then sends an encrypted email to
fake Glenn that is then subsequently read by the network systems
administrator.

La proposition que j'ai soulignée laisse supposer que GnuPG va automatiquement accorder à la clef de Roger une confiance entière, alors qu'il n'en est rien.

D'ailleurs tu peux très bien avoir une confiance absolue en Roger. Si le sysadmin parviens à infecter le portable de Roger avec un troyen pour s'emparer de ses clés, t'es foutu.

Exact. Mais je ne crois pas qu'il puisse exister la moindre parade contre cela, parce que tant qu'à faire, il peu aussi infecter le tien, de portable, c'est plus direct. Si Roger s'en rend compte, son devoir est de révoquer sa clef, et si un signataire de la clef de Roger s'en rend compte, il doit révoquer sa signature sur la clef de Roger.

Et si tu as confiance en 10 personnes, ça fait 10 point d'attaques.

Onze, en te comptant toi, et douze en comptant le destinataire des messages que tu veux envoyer. C'est vrai, ça c'est un défaut, et pas que de la toile de confiance à vrai dire : je n'imagine aucun système qui pourrait éviter cela.

Clair. Sans être techniquement « sexuellement explicite », cette animation reste objectivement assez crade et d'assez mauvais effet au boulot. Si un modo pouvait ajouter « [NSFW] » dans le titre, ce serait sans doute utile.

Après, c'est très curieux comme image, et je serais curieux de connaître son origine. Ça montre un acte qui relève du jeu érotique, plutôt sale — dans le même sens que le gobage de flamby est un jeu sale, pas propre quoi —, pas franchement élégant, et qui n'aurait rien de choquant dans un contexte privé, mais qui n'aurait pas due être publiée, pas plus qu'on ne publie des photos de soi en train de déféquer, de faire l'hélicoptère, de vomir ou de gober des flambys. Bref, c'est quoi ce délire ? Je vois mal Stallman publier ce genre de truc, donc est-ce un montage ? D'où cela sort-il ?

D'ailleurs, à y réfléchir, il me semble difficile de réaliser cela sans toucher l'arrière du palais, ce qui risque de déclencher un réflexe nauséeux. Montage donc ?

C'est marrant, c'est exactement ce que dit le paragraphe d'introduction de cette page :

Pretty Good Privacy is better than no encryption at all, and being end-to-end it is also better than relying on SMTP over TLS (that is, point-to-point between the mail servers while the message is unencrypted in-between), but is it still a good choice for the future? Is it something we should recommend to people who are asking for better privacy today?

Why the Web of Trust Sucks

Pas de chance, l'unique argument présenté dans ce message est faux. Il suppose que GnuPG accorde automatiquement une confiance entière à toutes les clefs identifiées comme valides, ou à la rigueur à toutes les clefs signées avec une indication de signature complète, ce qui n'est pas le cas.

Au contraire donc, GnuPG distingue bien ces deux notions :

• la validité d'une clef, c'est à dire le fait qu'elle appartienne bien à la personne indiquée ;
• le niveau de confiance que l'utilisateur accorde à cette personne, c'est à dire le fait qu'elle vérifie correctement les identités des gens avant de signer leurs clefs, et donc la valeur à accorder aux certifications qu'elle émet.

Le fonctionnement de GnuPG est donc une itération de deux étapes :

1. à partir des clefs valide auxquelles l'utilisateur accorde une confiance ultime, entière ou marginale, déterminer les nouvelles clefs valides, c'est à dire signées par au moins une clef à confiance ultime ou entière, ou trois clefs à confiance marginale ;
2. pour les nouvelles clefs valides, demander à l'utilisateur quelle confiance il accorde à leurs propriétaires : s'il s'agit d'un inconnu, l'utilisateur peut, et doit répondre « je ne sais pas », ce qui revient à lui accorder une confiance nulle.

Lorsqu'on certifie une clef, il est possible d'indiquer dans cette signature le niveau de confiance qu'on accorde à son propriétaire, mais, en tout cas pour GnuPG, il ne s'agit là que d'une information indicative, qu'il ne répercute pas automatiquement dans la base de confiance des utilisateurs. Ou plutôt, pour être plus précis :

1. si vous certifiez une clef en indiquant dans cette signature une confiance, disons entière, GnuPG ne vous proposera ensuite, comme niveau de confiance accordé à cette clef dans votre propre trousseau, que « entière » et « je ne sais pas » : ça, c'est plutôt cohérent, vous n'êtes pas censés mentir en émettant publiquement des signatures de confiance tout en appliquant quelque chose de différent à votre propre trousseau ;
2. si vous récupérez une clef signée par quelqu'un à qui vous accordez une confiance entière, et que cette signature précise une confiance, disons entière, GnuPG vous l'affichera si vous demandez la liste des signatures de cette nouvelle clef, mais n'appliquera pas ce niveau de confiance à cette nouvelle clef : comme pour toute nouvelle clef identifiée comme valide, vous devrez préciser librement le niveau de confiance à lui accorder.

Il y a autoblog qui sert à répliquer automatiquement des blogs pour contourner la censure publique ou privée par menaces de poursuites, mais je viens d'essayer, malheureusement :

• ça semble assez peu maintenu ;
• il existait une nouvelle version, presque une nouvelle implémentation si j'ai bien compris, mais elle a disparu ;
• c'est basé sur la capacité de PHP à ouvrir des URL distance à la place de fichiers locaux, qui est très, très peu fiable, pour avoir essayé.

Bref, j'ai essayé sur une Debian stable et sur une testing, ça ne fonctionne pas du tout. :-(

Certes, et j'ai hésité à l'écrire ainsi en hommage à l'ancienne ministre et à ses talents dans l'utilisation créative d'OpenOffice.org.

En effet.

Tout serveur supplémentaire devrait être utile. En ce qui concerne le reste du monde, c'est le problème du reste du monde, pas des européens, évidemment.

Vous noterez que cette blague empreinte un élément de la classique : c'est un homme qui entre dans un café, et plouf !

Tu peux ajouter à ta liste : service de nom faisant autorité en TCP. Oui, tinydns n'écoute qu'en UDP, parce qu'en TCP, « ça ne sert à rien ».

Qu'est-ce que c'est que ces trucs-là, tootella et incapsula ? C'est libre ? Ça sert à quoi ?

Les rôles ne sont pas séparés.

Tu penses au service de nom et au service de résolution récursive ? Cette non séparation est parfois un immense avantage au contraire, lorsque, disons, on est derrière un NAT : avec des services séparés, il faut configurer explicitement le résolveur pour interroger le serveur de nom avec son adresse locale pour les noms de domaines qu'on sert, sinon il essaiera une résolution récursive, et échouera à contacter l'autre serveur qui est derrière le même NAT que lui.

Le plus épatant que j'ai rencontré est djbdns.

Ça doit être le pire que j'ai rencontré au contraire. Logiciel non maintenu : de nouvelles fonctionnalités peuvent apparaître dans le DNS (IPv6, DNSSEC), il ne les prendra pas en charge puisque son auteur ne le mettra jamais à jour. Il utilise une syntaxe parfaitement non standard pour ses fichiers de zone. Il utilise un système de démarrage et de supervision de service alien.

Bref, c'est le serveur DNS qui était génial le jour où on a décidé de l'utiliser, puis qui devient au fil du temps une plaie donc il est dur de se débarrasser.

Avant de connaître ce petit bijou, j'étais persuadé d'être obligé de me cogner la configuration de BIND.

Comment ça, te cogner la configuration de BIND ? Dans les distributions bien conçues, il est livré avec une configuration tout à fait fonctionnelle, et il faut trois lignes et un fichier de zone pour ajouter une zone.

PowerDNS, c'est un serveur qui utilise une base de données SQL il me semble ? C'est là une caractéristique notable, parce qu'éliminatoire pour pas mal de gens.

Tu peux parler de fichiers de zone tout court, il n'y a pas d'ambiguïté.

VP9 est un codec Vidéo qui se veut un concurrent libre h265/hevc. Ce codec est développé par Google , il est le successeur de VP8 (codec crée par On2 puis racheté par Google) et est nativement inclu dans son navigateur internet Chrome/Chromium.

Rassure-moi, c'était fait exprès ?

Absolument aucune idée. À ma connaissance Iceweasel utilise les dictionnaires mypell ou hunspell, je n'en sais pas plus.

Pourquoi donc ?

relatime rulez.

Le cas OpenSSL c'était une erreur, sans le moindre doute, un cas inverse en fait, où un développeur Debian s'était amusé à faire du travail qui revenait au développeur amont, et l'avait mal fait.

C'est tout à fait réciproque : en général, un développeur amont ferait un mauvais empaqueteur, et un empaqueteur ferait un mauvais développeur amont.

Mais ils ont fait un choix délibéré en se rendant très bien compte de l'importance que ça avait.

Sans en discuter, sans l'annoncer, sans le justifier. Bref, je maintiens, on est là dans un très bel exemple de développeur amont qui serait un mauvais empaqueteur, et c'est normal, ce n'est pas ce qu'on lui demande. Les distributions sont là pour s'occuper de pour ce genre de problème, et dans ce cas précis, pour corriger une erreur amont — ce qui est une erreur, ce n'est pas forcément leur choix, s'ils arrivent à le justifier, ce qui n'est pas le cas aujourd'hui, mais la façon lamentable dont il a été effectué et mis en œuvre.

Amusant : j'ai effectué exactement la même chose il y a deux jours, et je comptais écrire un article, un peu plus bref sans doute, à ce sujet. Je compte toujours l'écrire, parce qu'il sera en anglais et plus ciblé je pense.

Seule différence dans mon cas : je démarre en UEFI. À part ça, même résultat : je migre à chaud, je redémarre et ça marche du premier coup.

Je n'ai jamais dit que les développeurs amont étaient bêtes ou malveillants, simplement, ce sont des développeurs, avec des compétences et des préoccupations différentes de celles des intégrateurs et des utilisateurs. Un bon développeur amont est généralement un mauvais empaqueteur, et c'est normal.

Là en revanche, on a un cas assez particulier, où les développeurs amont on décidé de changer quelque chose sans se rendre compte de l'importance que ça avait, puisque cela touchait à l'arborescence du système de fichier, domaine crucial pour l'intégration d'un système, auquel il n'est pas raisonnable de toucher sans discussion et consensus préalables. Cela leur a ensuite été signalé comme une erreur, mais ils ont maintenu leur choix sans être capables de le justifier. Et ça, c'est crade, mais ce n'est pas grave, comme je disais, les saletés des développeurs amont, ça se patche, ce ne sera pas la première fois, surtout dans ce domaine : le respect de la FHS est probablement le motif le plus fréquent des patchs apportés par Debian aux logiciels empaquetés.