Ce projet, pour ce que j’en ai compris, vise à répondre à la problématique « Comment obtenir la clé publique de mon correspondant ? »
Ce sera le sujet de mon prochain journal sur OpenPGP, mais je tiens quand même à dire dès maintenant qu’on a pas attendu le sieur Google pour se pencher sur la question…
Et pendant que Google élabore des solutions alambiquées dans son coin (on dirait que pour eux, si on ne parle pas de Merkle tree et de gossip protocol, ça ne vaut pas le coup), d’autres fournisseurs de messagerie utilisent une méthode déjà standardisée et pleinement prise en charge par GnuPG, la publication des clefs dans le DNS (RFC 7929).
En Europe on a un système relativement complexe de signes pour le code de la route, alors qu'aux US mis à part les symboles vraiment super courants, presque tout est écrit en anglais (et du coup l'universalité du code de la route en prend pour son grade)
Pour information, la signalisation routière telle que nous la connaissons en France est celle standardisée par la Convention de Vienne de 1968, à laquelle participent 65 pays (dont notamment la quasi-totalité de l’Europe, mais notamment pas les États-Unis d’Amérique). On est donc effectivement loin d’un code de la route « universel ».
Je ne sais pas pourquoi tu insistes dessus alors que je suis entièrement d'accord là dessus.
Ça répond aussi à Groumly qui semble penser que les pilotes sont dispensables et qu’une machine fera toujours mieux.
L'un n'empêche pas l'autre or tout le long du fil tu sembles sous-entendre que c'est incompatible.
Ce n’est pas incompatible, mais étant donné que des accidents comme celui de l’AF447 se produisent (et j’ai en tête quelques autres exemples similaires même si je ne me souviens pas assez des détails¹), je suis bien obligé de constater qu’il doit forcément y avoir des compagnies aériennes qui pensent que la sophistication croissante des avions autorise un certain laxisme.
¹ Je me souviens vaguement par exemple d’un crash à l’atterrissage provoqué (entre autres, ce n’était pas la seule cause) par le fait que le pilote ignorait que l’ordinateur de bord réduisait automatiquement les gaz dès que l’avion descendait en-dessous de 50 pieds. En fait, même la compagnie aérienne ignorait que ce comportement était codé dans la logique de l’avion, ils s’en sont rendu compte lors de l’enquête qui a suivi.
Car c'est vachement compliqué à faire. D'habitude tu as une aile qui touche la mer avant l'autre ce qui entraine un pivotement de l'appareil et du coup tout le monde et tout le matériel vont dans tous les sens…
Oui, et c’est notamment imputable (d’après les documentaires que j’ai vu sur l’accident) à l’assistance informatique de l’Airbus, qui a fait en sorte que l’avion reste parfaitement à l’horizontale (de sorte que les deux ailes touchent l’eau simultanément, empêchant précisément ce que tu évoques), en appliquant si nécessaires des micro-corrections aux commandes du pilote, facilitant considérablement la tâche de ce dernier.
Ce qui a été fait ce jour là relève de l'exploit
Un exploit résultant de la seule bonne combinaison : un avion techniquement à la pointe et un pilote qui sait exactement s’en servir (notamment, qui sait comment utiliser l’assistance informatique à son profit, au lieu de se faire surprendre par elle).
Un avion techniquement à la pointe entre les mains de pilotes pas assez formés, c’est le désastre (complètement évitable) du vol AF447.
Mais la machine les remplace de plus en plus et de manière fiable.
Formidable, mais encore une fois ça devient un problème lorsque ça justifie une réduction de l’entraînement des pilotes au motif que « la machine s’en charge ». Au contraire, les pilotes devraient s’entraîner encore plus, parce que leurs heures de vol ne leur font plus gagner autant d’expérience (vu que la plupart du temps c’est la machine qui est aux commandes).
Je me rappelle plus des détails du rapport sur le Paris/rio, mais si je ne m'abuse, le bea a mit la cause sur le copilote qui a ignoré l'alarme de décrochage et continuer à cabrer comme un cannu, ignorant ce que l'avion et le commandant de bord lui disaient.
En gros, oui. La cause profonde étant un singulier manque d’entraînement des pilotes face à ce genre de situation.
Pour remédier à ça, est-ce que tu préfères qu’on forme mieux les pilotes, où qu’on les remplace complètement par un ordinateur ?
Pour ma part, tant qu’un ordinateur n’aura pas réussi à poser tout seul un avion privé de moteurs sur une rivière (vol US Airways 1547, qui est pour moi le contre-exemple parfait du vol AF447), je ne me passerai pas de pilotes.
Je veux dire, en deux mots, à quel endroit prend-il ses infos ? En quoi ses sources sont-elles fiables ?
Il prend ses infos en contactant directement les serveurs faisant autorité, sans passer par un intermédiaire.
Il faut comprendre la différence entre un stub resolver et un full resolver (aussi appelé résolver récursif).
Seul un résolveur récursif est capable de répondre pleinement à une question, en émettant autant de requêtes que nécessaire auprès des différents serveurs faisant autorité jusqu’à obtenir une réponse. Par exemple, pour obtenir l’adresse de www.example.com., un résolveur récursif contactera successivement un des serveurs faisant autorité pour la racine (qui lui répondra en gros « je connais pas www.example.com., mais demande aux serveurs faisant autorité pour com., c’est leur rayon »), puis un des serveurs faisant autorité pour com., puis finalement un des serveurs faisant autorité pour example.com..
Un stub resolver, en revanche, peut seulement transmettre la demande à un résolveur récursif et en attendre la réponse.
En général, par défaut le résolveur du système d’exploitation est un stub resolver, qui ne peut donc rien faire tout seul. Il doit être configuré avec l’adresse d’un ou plusieurs serveurs récursifs (typiquement, ceux indiqués par le FAI) à qui transmettre les demandes.
Installer un « DNS perso », dans ce contexte, consiste à remplacer le stub resolver du système par un résolveur récursif (comme Unbound par exemple), dispensant ainsi de la nécessité d’utiliser un résolveur récursif fourni par un tiers.
C'est pourtant comme cela que fonctionne les auto-pilotes dans l'aéronautique, le pilote n'intervient que quand l'auto-pilote n'y parvient pas (ou que le pilote décide de reprendre la main pour X raisons).
Et ce n’est pas fait pour me rassurer.
Plusieurs catastrophes aériennes auraient été parfaitement évitables si les pilotes ne s’étaient pas trop reposés sur l’automation, et si les compagnies aériennes n’en avaient pas profité pour lâcher du lest sur l’entraînement des pilotes. Le vol Air France 447 Rio–Paris en est un bon exemple.
La Google car est au niveau 3, c'est à dire qu'il faut un conducteur prêt à reprendre les commandes si le véhicule (ou le conducteur lui-même) le décide.
Ça aussi c’est un principe qui me fait peur. La voiture qui s’occupe de tout, mais qui rend la main au conducteur dans les cas non-prévus.
Je comprends bien l’idée derrière (le conducteur humain a une ingéniosité, un instinct, ou appelez-ça comme vous voulez, que le logiciel de la voiture n’a pas, et il pourra trouver une solution là où la voiture en est incapable), c’est juste que je n’y crois pas trop.
On a un conducteur qui n’est déjà plus habitué à conduire dans les situations faciles (puisque dans ces situations c’est la voiture qui fait tout), et c’est au moment où une situation difficile (trop pour que la voiture puisse la gérer) se présente que la voiture lui dit « tiens, débrouille-toi, moi j’abandonne ! ». Et on espère que le conducteur va pouvoir s’en sortir ?!
C’est comme l’auto-parking par exemple. Très bien tant que ça marche, mais le jour où (pour une raison ou un autre) la voiture n’arrive pas à se ranger toute seule, comment un conducteur qui n’a plus fait de rangement en créneau lui-même depuis des mois voire des années va-t-il pouvoir faire mieux ?
Je pense que justement il n'y aura pas besoin de beaucoup d'équipements routiers pour eux.
Tu as vu la vidéo du « projet d’intersections automatisées » ? Le projet suppose une communication entre le véhicule et un « serveur d’intersection » à chaque intersection, pour que le véhicule sache s’il peut s’engager ou non dans l’intersection en question.
Ça suppose donc une connection disponible en tout point du réseau routier.
la communication entre voitures d'une certaine zone directement.
Là je vois bien venir le projet foireux où tout le monde partira sur le principe que chaque véhicule n’a que de bonnes intentions et jouera le jeu correctement. Personne (à part des gus dans un garage que personne n’écoutera comme d’habitude) n’imaginera qu’une personne mal intentionnée puisse exploiter le système à son profit. Ai-je déjà mentionné que la sécurité dans l’Internet des objets avait vingt ans de retard ?
Le mélange de tout ceci pourrait permettre une bonne fiabilité dans le processus assez facilement
Oui, euh, alors avant que je ne confie ma vie à un véhicule entièrement autonome, il va me falloir un peu plus qu’une vague promesse de « bonne fiabilité ». Je veux au minimum le niveau de fiabilité qu’on attend d’un avion commercial, pas celui qu’on attend d’un gadget USB qui plante un 29 février parce que le développeur avait oublié l’existence des années bissextiles.
le code de la route et la voirie pourront être spécifiquement conçus pour être utilisés uniquement par des machines et ainsi gagner toujours plus en efficacité et en sécurité, comme la vidéo de ce projet d'intersections automatisées le montre.
Quand je vois sans même aller très loin le nombre d’intersections où les marquages au sol sont devenus à peine visible, ou des panneaux tellement tordus qu’ils sont pratiquement à l’horizontale et ce depuis des lustres… j’ai de gros doutes sur la faisabilité d’installer et surtout d’entretenir ce genre d’équipements « intelligents » sur la totalité du réseau routier. Si la bonne conduite des véhicules autonomes dépend de la présence de ces équipements et de leur bon fonctionnement en toutes circonstances, on va à la catastrophe.
(Et je ne parlerai même pas des problèmes de sécurité informatique, étant entendu que la sécurité dans le monde de « l’Internet des objets » est à peu près au niveau de celle de Windows 3.11 — soit vingt ans de retard au moins.)
OK on ne devrait pas jeter la chose, mais mettre une pièce jointe inutile
Ouais, ce n’est jamais qu’une pratique standardisée depuis… 1995 (RFC 1847). Clairement, ce n’est pas la faute des développeurs de clients de mails de 2017 s’ils ne prennent pas ça en charge.
Qu’il y a une solution simple : Guile 1.8 et Guile 2.0 peuvent parfaitement cohabiter sur le même système.
Je le sais, parce que j’ai été confronté au même problème lorsque Slackware est passé de Guile 1.8 à Guile 2.0 : tout d’un coup, je ne pouvais plus compiler Lilypond. Sauf qu’en fait il n’y a aucun problème : j’ai juste installé Guile-1.8 à côté, et tout le monde est content.
Pourquoi cette solution n’est pas acceptable pour Debian ?
Mais ce n'est pas un peu égoïste de faire ainsi ? […] je dois quand même taper les serveurs racine chaque jour (et juste pour moi).
Pifométriquement, je pense qu’il n’y a guère de soucis à se faire du côté des serveurs racines. Ils encaissent plus ou moins régulièrement des tentatives de DDoS sans jamais s’écrouler, ils tiendraient probablement largement la charge même si tout le monde se mettait à utiliser son propre résolveur.
C’est plutôt les serveurs faisant autorité pour les zones très populaires (au hasard, google.com., facebook.com., etc.) qui risqueraient de « prendre cher ». Mais là aussi, les hébergeurs DNS de ce genre de zones « à risque » savent probablement à quoi s’en tenir (ils se prennent probablement leur dose d’attaques DDoS eux aussi, comme les serveurs racines).
Contre-exemple : Edward aux mains d’argent, c’est quand même ’achement plus joli à mon goût que Edward Scissorhands, même si c’est éloigné du sens original (comme on dit : Traduttore, traditore).
Le mien. J’utilise un résolveur récursif qui fait lui-même tout le travail de résolution (contacter les serveurs faisant autorité et suivre les différentes délégations), pas un stub resolver qui se contente de transmettre la demande à des résolveurs tiers (que ce soit ceux du FAI ou d’autres).
Comme ça, la validation DNSSEC est faite sur ma machine, ça règle la question de la « sécurité du dernier kilomètre ».
Question anonymat en revanche, ça ne change pas grand’chose vis-à-vis du FAI, qui voit de toute façon passer toutes les requêtes DNS, peu importe qu’elles soient destinées directement aux serveurs faisant autorité ou qu’elles passent par un résolveur tiers.
Et vis-à-vis des serveurs faisant autorité, ça fait même perdre un peu d’anonymat par rapport à l’utilisation des résolveurs du FAI, puisque d’une part c’est ma machine (avec mon IP) qui le contacte et non plus le résolveur du FAI, et d’autre part je ne bénéficie plus du cache du résolveur du FAI.
En ces temps de censure du net
Si c’est la censure qui te préoccupe (et non la vie privée), alors a fortiori il faut éviter autant que possible les intermédiaires inutiles et procéder à la résolution soi-même. Tout intermédiaire est un levier potentiel pour les censeurs.
Plus que léger, ha bon, tu dois être vraiment bon dans le domaine pour bypasser l'avis d'une revue a comité de relecture.
Je réagis juste là-dessus (ni le temps ni l’envie de participer au reste de la discussion) :
Attention à ne pas accorder à la relecture par les pairs (peer review) une signification qu’elle n’a pas.
Le simple fait d’être publiée dans une revue à comité de relecture n’a jamais signifié qu’une étude était bonne. Des revues à comité de relecture qui publient de la mauvaise science, ça existe. Dans le meilleur des cas c’est occasionnel, dans le pire c’est le business model de la revue qui veut ça (cas notamment des predatory publishers, qui publient à peu près n’importe quoi tant qu’on les paie — tout en prétendant faire de la peer review).
Accorder le moindre crédit à une étude seulement parce qu’elle a été publiée dans telle revue à comité de relecture, c’est un peu l’équivalent scientifique de croire n’importe quelle information au prétexte « qu’ils l’ont dit au journal télévisé. » (Et la notoriété ou l’impact factor de la revue n’y changent rien.)
Le seul moyen de savoir si une étude est sérieuse ou non, c’est de la lire et de la comprendre. Et quand tu l’as fait (si tu as le niveau pour ça), il est complètement normal de ne plus tenir compte que de ton propre avis et de « bypasser » l’avis de l’éditeur et des relecteurs, ça n’a rien à voir avec de l’ego ou de la suffisance.
Ca me fait doucement rire un dev qui pretend savoir ce qui est mieux pour l'utilisateur dans le domaine face a des professionnels de la recherche musicale.
Personne ici n’a prétendu que PulseAudio était adapté à l’audio pro. Certainement pas moi, et Lennart Poettering non plus :
many pro audio folks are not sure what Jack does that PulseAudio doesn't do and what PulseAudio does that Jack doesn't do; why they are not competing, why you cannot replace one by the other, and why merging them (at least in the short term) might not make immediate sense. In other words, why millions of phones on this world run PulseAudio and not Jack, and why a music studio running PulseAudio is crack.
Jack n’est pas adapté au desktop et PulseAudio n’est pas adapté à l’audio pro, c’est si difficile à comprendre ?
Et avant qu’on n’en fasse la remarque : non, la seule existence de deux piles audio (une pour l’usage générique, une pour les usages plus exigeants) n’est pas un symptôme de l’incapacité des développeurs de logiciels libres à s’entendre et à proposer des solutions unifiées. Pour rappel, sous Windows aussi il y a DirectSound pour l’usage générique, et ASIO pour l’audio pro (développé par Steinberg parce que la pile audio native de Windows, qui est certainement très bien, n’est juste pas adaptée pour certains usages).
Merci pour cet énorme moment d'humour !! Déjà il est super simple d'écrire une backdoor qui passe pour un bug tout con,
Intéressant. :) Tu veux donc dire qu'il est facile d'écrire une correction de bug pour le noyau Linux ou Firefox qui contient une porte dérobée […] ?C'est déjà arrivé ? Tu as un exemple précis à nous donner ou c'est un simple FUD ? :-)
La tentative a été découverte avant d’aller bien loin, mais le fait est qu’écrire du code C malveillant (backdoor ou autre) qui ressemble à une simple erreur de programmation (de telle sorte que l’auteur puisse dire, en cas de découverte, « oups, c’est une boulette, désolé ») n’a rien d’exceptionnel. Il y a même un concours consacré à ça je crois.
Je plussoie, ça fait plusieurs années que je le dis. Sur le simple principe du qui peut le plus peut le moins.
Et il y a des années j’ai déjà expliqué pourquoi c’était une mauvaise idée. Auto-citation :
PulseAudio et Jack n’ont pas du tout les mêmes objectifs, ce sur quoi s’accordent leurs développeurs respectifs : voici ce qu’en dit Lennart Poettering, et ce qu’en dit Paul Davis (beaucoup plus succintement, dans le deuxième paragraphe). Les deux serveurs ne sont donc pas interchangeables.
Par exemple, là où PulseAudio s’accommode de sources utilisant des formats différents (fréquence et taille des échantillons), Jack impose un format unique à tous ses clients, ce qui n’est pas forcément judicieux pour un serveur de son qui serait destiné à être utilisé par toutes les applications du bureau (alors que c’est parfaitement acceptable pour les quelques applications dédiées à l’audio pro).
Du coup, le principe du « qui peut le plus peut le moins » n’est pas applicable ici, ou du moins pas dans le sens que tu souhaites : en fait c’est PulseAudio qui en fait « plus » que Jack (d’où sa plus grande complexité).
c'est une documentation sur SSH, à laquelle j'ai participé d'ailleurs.
Il me semble que cette partie n’est pas correcte :
Le client génère une clef secrète et l'envoie au serveur, en chiffrant l'échange avec la clef publique du serveur […] Une fois la clef secrète échangée, le client et le serveur peuvent alors établir un canal sécurisé grâce à la clef secrète commune
Cela sous-entend que la paire de clefs asymétriques du serveur est utilisé à la fois pour authentifier le serveur auprès du client, et pour chiffrer la clef de session (symétrique).
Je ne crois pas que ça se passe ainsi. La paire de clefs asymétriques est utilisé pour l’authentification uniquement. Une fois le serveur authentifié, le serveur et le client procèdent à un échange Diffie-Hellman pour obtenir tous les deux la clef de session symétrique ; cet échange n’implique pas la paire de clefs asymétriques du serveur.
C’est un détail qui a son importance, car cela implique qu’une éventuelle compromission ultérieure de la clef privée du serveur ne permettra pas de déchiffrer les clefs de session et donc de revenir déchiffrer le traffic enregistré (alors que ce serait possible si les clefs de session étaient directement chiffrées avec la clef publique du serveur).
En revanche, pendant que tu es connecté par SSH quelque part, elle reste la même. À moins qu'il n'y ait un mécanisme de renégociation, je n'ai pas vérifié.
Oui, un tel mécanisme existe. Le RFC 4253 suggère une telle re-négociation chaque fois qu’un giga-octets de données a été transféré, ou après chaque heure écoulée. Dans OpenSSH, ça se configure avec l’option RekeyLimit.
Pas de sources formelles malheureusement. Principalement un billet de Maître Eolas d’il y a quelques années à propos de « l’affaire Bourreau-Guggenheim » (cet employé de TF1 qui a été viré après que le message qu’il avait envoyé à son député, dans lequel il exposait une position contre HADOPI, avait été transmis à TF1 — le point de Maitre Eolas étant qu’il n’y avait rien de légalement répréhensible de la part du député qui a transmis le message).
Il me semblait que divulguer un courriel tombait sous le coup de l'article L226-15 du code pénal en France. Mais en le relisant, j'en suis moins sûr…
Je cite Maître Eolas (lien ci-dessus) :
Il n'y a nulle atteinte au secret des correspondances dès lors que celui qui en prend connaissance a reçu délégation expresse du destinataire pour ce faire. L'atteinte au secret des correspondances (art. 226-15 du code pénal) suppose la mauvaise foi ou la fraude, c'est à dire la conscience que le courrier n'est pas adressé à celui qui en prend connaissance et qu'il n'a pas l'autorisation pour ce faire.
Dans le cas, où l'on est le destinataire, ne faudrait-il pas malgré tout l'accord de l'émetteur ?
Bah non. Encore une fois, il est généralement mal vu de ne pas demander l’accord de l’émetteur (j’ai vu ça plusieurs fois dans des listes de discussion par exemple, où quelqu’un poste sur la liste des extraits d’un message qui n’avait été envoyé qu’à lui — il y a toujours au moins une personne qui interpelle « avez-vous demandé à M. Smith s’il était d’accord pour que ses propos se retrouvent sur une liste publique ? »), mais — en droit français du moins — ce n’est pas obligatoire.
Et le fournisseur ne peut-il pas être considéré comme un tiers justement ?
Le fournisseur est un tiers, mais en signant chez lui le destinataire lui a donné l’autorisation de prendre connaissance du message. Certes, l’émetteur lui n’a pas donné cette autorisation, mais elle n’est pas requise si l’on admet que le destinataire a le droit de faire ce qu’il veut du message.
Vous m’écrivez depuis une adresse mail dont le fournisseur ne respecte pas ma
vie privée et pour lequel je n’ai aucunement approuvé ses conditions générales
d’utilisation liberticides.
Depuis quand faut-il accepter les CGU du fournisseur de son interlocuteur ?
Ce que fait Gafam des messages que tu envoies à jean.michu@gafam.example est l’affaire de Gafam et de Jean Michu uniquement.
Je rappelle à toutes fins utiles que le destinataire d’un message est libre d’en faire ce que bon lui semble, indépendamment de ce que peut penser ou souhaiter son envoyeur. (Notamment, et contrairement à une idée qui semble répandue, le « secret des correspondances » ne lui est pas opposable. Le destinataire d’un message privé peut tout-à-fait le transmettre à un tiers ou même le rendre public — c’est souvent mal vu et considéré comme incorrect si on n’a pas l’accord express de l’expéditeur, mais ce n’est pas interdit.)
Du coup, si Jean Michu a décidé que ton message devait être traité par les services de Gafam, d’après moi c’est son droit le plus strict et je ne vois rien d’anormal à ce qu’on ne t’ait pas demandé ton avis.
Votre mail ne recevra donc aucune réponse de ma part, afin de ne pas continuer
à fournir mes données privées à votre fournisseur.
À moins d’utiliser du chiffrement de bout-en-bout, n’importe quel fournisseur peut prendre connaissance du contenu de tes messages et des méta-données qui vont avec. Ce n’est pas parce que les GAFAM sont bien connus pour le faire qu’il faut s’imaginer qu’ils sont les seuls.
Si tu ne veux pas fournir des données privées au fournisseur de ton interlocuteur, tu chiffres, ou tu n’envois pas de données privées.
[^] # Re: Une avancée
Posté par gouttegd . En réponse au journal Google chiffrement de mail end to end . Évalué à 4.
Ce sera le sujet de mon prochain journal sur OpenPGP, mais je tiens quand même à dire dès maintenant qu’on a pas attendu le sieur Google pour se pencher sur la question…
Et pendant que Google élabore des solutions alambiquées dans son coin (on dirait que pour eux, si on ne parle pas de Merkle tree et de gossip protocol, ça ne vaut pas le coup), d’autres fournisseurs de messagerie utilisent une méthode déjà standardisée et pleinement prise en charge par GnuPG, la publication des clefs dans le DNS (RFC 7929).
[^] # Re: Le code de la route n'est rien d'autre qu'un ensemble de protocoles pour réseaux routiers
Posté par gouttegd . En réponse au journal Et vous, vous voulez qu'elle fasse quoi votre voiture autonome ?. Évalué à 2.
Pour information, la signalisation routière telle que nous la connaissons en France est celle standardisée par la Convention de Vienne de 1968, à laquelle participent 65 pays (dont notamment la quasi-totalité de l’Europe, mais notamment pas les États-Unis d’Amérique). On est donc effectivement loin d’un code de la route « universel ».
[^] # Re: Le code de la route n'est rien d'autre qu'un ensemble de protocoles pour réseaux routiers
Posté par gouttegd . En réponse au journal Et vous, vous voulez qu'elle fasse quoi votre voiture autonome ?. Évalué à 2.
Ça répond aussi à Groumly qui semble penser que les pilotes sont dispensables et qu’une machine fera toujours mieux.
Ce n’est pas incompatible, mais étant donné que des accidents comme celui de l’AF447 se produisent (et j’ai en tête quelques autres exemples similaires même si je ne me souviens pas assez des détails¹), je suis bien obligé de constater qu’il doit forcément y avoir des compagnies aériennes qui pensent que la sophistication croissante des avions autorise un certain laxisme.
¹ Je me souviens vaguement par exemple d’un crash à l’atterrissage provoqué (entre autres, ce n’était pas la seule cause) par le fait que le pilote ignorait que l’ordinateur de bord réduisait automatiquement les gaz dès que l’avion descendait en-dessous de 50 pieds. En fait, même la compagnie aérienne ignorait que ce comportement était codé dans la logique de l’avion, ils s’en sont rendu compte lors de l’enquête qui a suivi.
[^] # Re: Le code de la route n'est rien d'autre qu'un ensemble de protocoles pour réseaux routiers
Posté par gouttegd . En réponse au journal Et vous, vous voulez qu'elle fasse quoi votre voiture autonome ?. Évalué à 3.
Oui, et c’est notamment imputable (d’après les documentaires que j’ai vu sur l’accident) à l’assistance informatique de l’Airbus, qui a fait en sorte que l’avion reste parfaitement à l’horizontale (de sorte que les deux ailes touchent l’eau simultanément, empêchant précisément ce que tu évoques), en appliquant si nécessaires des micro-corrections aux commandes du pilote, facilitant considérablement la tâche de ce dernier.
Un exploit résultant de la seule bonne combinaison : un avion techniquement à la pointe et un pilote qui sait exactement s’en servir (notamment, qui sait comment utiliser l’assistance informatique à son profit, au lieu de se faire surprendre par elle).
Un avion techniquement à la pointe entre les mains de pilotes pas assez formés, c’est le désastre (complètement évitable) du vol AF447.
Formidable, mais encore une fois ça devient un problème lorsque ça justifie une réduction de l’entraînement des pilotes au motif que « la machine s’en charge ». Au contraire, les pilotes devraient s’entraîner encore plus, parce que leurs heures de vol ne leur font plus gagner autant d’expérience (vu que la plupart du temps c’est la machine qui est aux commandes).
[^] # Re: Le code de la route n'est rien d'autre qu'un ensemble de protocoles pour réseaux routiers
Posté par gouttegd . En réponse au journal Et vous, vous voulez qu'elle fasse quoi votre voiture autonome ?. Évalué à 3.
En gros, oui. La cause profonde étant un singulier manque d’entraînement des pilotes face à ce genre de situation.
Pour remédier à ça, est-ce que tu préfères qu’on forme mieux les pilotes, où qu’on les remplace complètement par un ordinateur ?
Pour ma part, tant qu’un ordinateur n’aura pas réussi à poser tout seul un avion privé de moteurs sur une rivière (vol US Airways 1547, qui est pour moi le contre-exemple parfait du vol AF447), je ne me passerai pas de pilotes.
[^] # Re: apt-get install unbound
Posté par gouttegd . En réponse au sondage Quel résolveur DNS utilisez-vous ?. Évalué à 7.
Il prend ses infos en contactant directement les serveurs faisant autorité, sans passer par un intermédiaire.
Il faut comprendre la différence entre un stub resolver et un full resolver (aussi appelé résolver récursif).
Seul un résolveur récursif est capable de répondre pleinement à une question, en émettant autant de requêtes que nécessaire auprès des différents serveurs faisant autorité jusqu’à obtenir une réponse. Par exemple, pour obtenir l’adresse de
www.example.com., un résolveur récursif contactera successivement un des serveurs faisant autorité pour la racine (qui lui répondra en gros « je connais paswww.example.com., mais demande aux serveurs faisant autorité pourcom., c’est leur rayon »), puis un des serveurs faisant autorité pourcom., puis finalement un des serveurs faisant autorité pourexample.com..Un stub resolver, en revanche, peut seulement transmettre la demande à un résolveur récursif et en attendre la réponse.
En général, par défaut le résolveur du système d’exploitation est un stub resolver, qui ne peut donc rien faire tout seul. Il doit être configuré avec l’adresse d’un ou plusieurs serveurs récursifs (typiquement, ceux indiqués par le FAI) à qui transmettre les demandes.
Installer un « DNS perso », dans ce contexte, consiste à remplacer le stub resolver du système par un résolveur récursif (comme Unbound par exemple), dispensant ainsi de la nécessité d’utiliser un résolveur récursif fourni par un tiers.
[^] # Re: Le code de la route n'est rien d'autre qu'un ensemble de protocoles pour réseaux routiers
Posté par gouttegd . En réponse au journal Et vous, vous voulez qu'elle fasse quoi votre voiture autonome ?. Évalué à 1.
Le fait que des accidents aient été évités grâce à l’automation ne peut en aucun cas justifier un laxisme qui cause d’autres accidents.
Je ne critique pas l’automation, je critique la confiance voire l’optimisme béat que l’on place en elle.
[^] # Re: Le code de la route n'est rien d'autre qu'un ensemble de protocoles pour réseaux routiers
Posté par gouttegd . En réponse au journal Et vous, vous voulez qu'elle fasse quoi votre voiture autonome ?. Évalué à 1.
Et ce n’est pas fait pour me rassurer.
Plusieurs catastrophes aériennes auraient été parfaitement évitables si les pilotes ne s’étaient pas trop reposés sur l’automation, et si les compagnies aériennes n’en avaient pas profité pour lâcher du lest sur l’entraînement des pilotes. Le vol Air France 447 Rio–Paris en est un bon exemple.
[^] # Re: Le code de la route n'est rien d'autre qu'un ensemble de protocoles pour réseaux routiers
Posté par gouttegd . En réponse au journal Et vous, vous voulez qu'elle fasse quoi votre voiture autonome ?. Évalué à 2.
Ça aussi c’est un principe qui me fait peur. La voiture qui s’occupe de tout, mais qui rend la main au conducteur dans les cas non-prévus.
Je comprends bien l’idée derrière (le conducteur humain a une ingéniosité, un instinct, ou appelez-ça comme vous voulez, que le logiciel de la voiture n’a pas, et il pourra trouver une solution là où la voiture en est incapable), c’est juste que je n’y crois pas trop.
On a un conducteur qui n’est déjà plus habitué à conduire dans les situations faciles (puisque dans ces situations c’est la voiture qui fait tout), et c’est au moment où une situation difficile (trop pour que la voiture puisse la gérer) se présente que la voiture lui dit « tiens, débrouille-toi, moi j’abandonne ! ». Et on espère que le conducteur va pouvoir s’en sortir ?!
C’est comme l’auto-parking par exemple. Très bien tant que ça marche, mais le jour où (pour une raison ou un autre) la voiture n’arrive pas à se ranger toute seule, comment un conducteur qui n’a plus fait de rangement en créneau lui-même depuis des mois voire des années va-t-il pouvoir faire mieux ?
[^] # Re: Le code de la route n'est rien d'autre qu'un ensemble de protocoles pour réseaux routiers
Posté par gouttegd . En réponse au journal Et vous, vous voulez qu'elle fasse quoi votre voiture autonome ?. Évalué à 2.
Tu as vu la vidéo du « projet d’intersections automatisées » ? Le projet suppose une communication entre le véhicule et un « serveur d’intersection » à chaque intersection, pour que le véhicule sache s’il peut s’engager ou non dans l’intersection en question.
Ça suppose donc une connection disponible en tout point du réseau routier.
Là je vois bien venir le projet foireux où tout le monde partira sur le principe que chaque véhicule n’a que de bonnes intentions et jouera le jeu correctement. Personne (à part des gus dans un garage que personne n’écoutera comme d’habitude) n’imaginera qu’une personne mal intentionnée puisse exploiter le système à son profit. Ai-je déjà mentionné que la sécurité dans l’Internet des objets avait vingt ans de retard ?
Oui, euh, alors avant que je ne confie ma vie à un véhicule entièrement autonome, il va me falloir un peu plus qu’une vague promesse de « bonne fiabilité ». Je veux au minimum le niveau de fiabilité qu’on attend d’un avion commercial, pas celui qu’on attend d’un gadget USB qui plante un 29 février parce que le développeur avait oublié l’existence des années bissextiles.
[^] # Re: Le code de la route n'est rien d'autre qu'un ensemble de protocoles pour réseaux routiers
Posté par gouttegd . En réponse au journal Et vous, vous voulez qu'elle fasse quoi votre voiture autonome ?. Évalué à 4.
Quand je vois sans même aller très loin le nombre d’intersections où les marquages au sol sont devenus à peine visible, ou des panneaux tellement tordus qu’ils sont pratiquement à l’horizontale et ce depuis des lustres… j’ai de gros doutes sur la faisabilité d’installer et surtout d’entretenir ce genre d’équipements « intelligents » sur la totalité du réseau routier. Si la bonne conduite des véhicules autonomes dépend de la présence de ces équipements et de leur bon fonctionnement en toutes circonstances, on va à la catastrophe.
(Et je ne parlerai même pas des problèmes de sécurité informatique, étant entendu que la sécurité dans le monde de « l’Internet des objets » est à peu près au niveau de celle de Windows 3.11 — soit vingt ans de retard au moins.)
[^] # Re: Pas que Pole Emploi
Posté par gouttegd . En réponse au journal Échanger des courriels avec Pôle-Emploi, ça peut être compliqué. Évalué à 7.
Ouais, ce n’est jamais qu’une pratique standardisée depuis… 1995 (RFC 1847). Clairement, ce n’est pas la faute des développeurs de clients de mails de 2017 s’ils ne prennent pas ça en charge.
# Cohabitation de versions
Posté par gouttegd . En réponse au journal LilyPond ne sera pas dans Debian Stretch. Évalué à 10.
Qu’il y a une solution simple : Guile 1.8 et Guile 2.0 peuvent parfaitement cohabiter sur le même système.
Je le sais, parce que j’ai été confronté au même problème lorsque Slackware est passé de Guile 1.8 à Guile 2.0 : tout d’un coup, je ne pouvais plus compiler Lilypond. Sauf qu’en fait il n’y a aucun problème : j’ai juste installé Guile-1.8 à côté, et tout le monde est content.
Pourquoi cette solution n’est pas acceptable pour Debian ?
[^] # Re: Le mien
Posté par gouttegd . En réponse au journal DNS anonyme. Évalué à 4.
Pifométriquement, je pense qu’il n’y a guère de soucis à se faire du côté des serveurs racines. Ils encaissent plus ou moins régulièrement des tentatives de DDoS sans jamais s’écrouler, ils tiendraient probablement largement la charge même si tout le monde se mettait à utiliser son propre résolveur.
C’est plutôt les serveurs faisant autorité pour les zones très populaires (au hasard,
google.com.,facebook.com., etc.) qui risqueraient de « prendre cher ». Mais là aussi, les hébergeurs DNS de ce genre de zones « à risque » savent probablement à quoi s’en tenir (ils se prennent probablement leur dose d’attaques DDoS eux aussi, comme les serveurs racines).[^] # Re: "Le Cloud Computing" (ou Infonuagique en français)
Posté par gouttegd . En réponse au journal C'est quoi le "cloud computing" ? 1/2. Évalué à 4.
Contre-exemple : Edward aux mains d’argent, c’est quand même ’achement plus joli à mon goût que Edward Scissorhands, même si c’est éloigné du sens original (comme on dit : Traduttore, traditore).
# Le mien
Posté par gouttegd . En réponse au journal DNS anonyme. Évalué à 10.
Le mien. J’utilise un résolveur récursif qui fait lui-même tout le travail de résolution (contacter les serveurs faisant autorité et suivre les différentes délégations), pas un stub resolver qui se contente de transmettre la demande à des résolveurs tiers (que ce soit ceux du FAI ou d’autres).
Comme ça, la validation DNSSEC est faite sur ma machine, ça règle la question de la « sécurité du dernier kilomètre ».
Question anonymat en revanche, ça ne change pas grand’chose vis-à-vis du FAI, qui voit de toute façon passer toutes les requêtes DNS, peu importe qu’elles soient destinées directement aux serveurs faisant autorité ou qu’elles passent par un résolveur tiers.
Et vis-à-vis des serveurs faisant autorité, ça fait même perdre un peu d’anonymat par rapport à l’utilisation des résolveurs du FAI, puisque d’une part c’est ma machine (avec mon IP) qui le contacte et non plus le résolveur du FAI, et d’autre part je ne bénéficie plus du cache du résolveur du FAI.
Si c’est la censure qui te préoccupe (et non la vie privée), alors a fortiori il faut éviter autant que possible les intermédiaires inutiles et procéder à la résolution soi-même. Tout intermédiaire est un levier potentiel pour les censeurs.
[^] # Re: Courage à toi
Posté par gouttegd . En réponse au journal Morts du cancer, quelle honte !. Évalué à 8.
Je réagis juste là-dessus (ni le temps ni l’envie de participer au reste de la discussion) :
Attention à ne pas accorder à la relecture par les pairs (peer review) une signification qu’elle n’a pas.
Le simple fait d’être publiée dans une revue à comité de relecture n’a jamais signifié qu’une étude était bonne. Des revues à comité de relecture qui publient de la mauvaise science, ça existe. Dans le meilleur des cas c’est occasionnel, dans le pire c’est le business model de la revue qui veut ça (cas notamment des predatory publishers, qui publient à peu près n’importe quoi tant qu’on les paie — tout en prétendant faire de la peer review).
Accorder le moindre crédit à une étude seulement parce qu’elle a été publiée dans telle revue à comité de relecture, c’est un peu l’équivalent scientifique de croire n’importe quelle information au prétexte « qu’ils l’ont dit au journal télévisé. » (Et la notoriété ou l’impact factor de la revue n’y changent rien.)
Le seul moyen de savoir si une étude est sérieuse ou non, c’est de la lire et de la comprendre. Et quand tu l’as fait (si tu as le niveau pour ça), il est complètement normal de ne plus tenir compte que de ton propre avis et de « bypasser » l’avis de l’éditeur et des relecteurs, ça n’a rien à voir avec de l’ego ou de la suffisance.
[^] # Re: Voila ce qui arrive
Posté par gouttegd . En réponse au journal ON Y EST ENFIN !. Évalué à 10.
Personne ici n’a prétendu que PulseAudio était adapté à l’audio pro. Certainement pas moi, et Lennart Poettering non plus :
Jack n’est pas adapté au desktop et PulseAudio n’est pas adapté à l’audio pro, c’est si difficile à comprendre ?
Et avant qu’on n’en fasse la remarque : non, la seule existence de deux piles audio (une pour l’usage générique, une pour les usages plus exigeants) n’est pas un symptôme de l’incapacité des développeurs de logiciels libres à s’entendre et à proposer des solutions unifiées. Pour rappel, sous Windows aussi il y a DirectSound pour l’usage générique, et ASIO pour l’audio pro (développé par Steinberg parce que la pile audio native de Windows, qui est certainement très bien, n’est juste pas adaptée pour certains usages).
[^] # Re: Ca veut dire quoi "être prêt pour le desktop" ?
Posté par gouttegd . En réponse au journal ON Y EST ENFIN !. Évalué à 4.
Oui, c’est déjà arrivé.
La tentative a été découverte avant d’aller bien loin, mais le fait est qu’écrire du code C malveillant (backdoor ou autre) qui ressemble à une simple erreur de programmation (de telle sorte que l’auteur puisse dire, en cas de découverte, « oups, c’est une boulette, désolé ») n’a rien d’exceptionnel. Il y a même un concours consacré à ça je crois.
[^] # Re: Voila ce qui arrive
Posté par gouttegd . En réponse au journal ON Y EST ENFIN !. Évalué à 6.
Et il y a des années j’ai déjà expliqué pourquoi c’était une mauvaise idée. Auto-citation :
[^] # Re: Ca veut dire quoi "être prêt pour le desktop" ?
Posté par gouttegd . En réponse au journal ON Y EST ENFIN !. Évalué à 5.
Ben… oui, si j’en juge par le nombre de fois où on m’a demandé de le faire « parce que moi j’y connais rien à ces trucs, là, toi tu maîtrises ».
[^] # Re: Éléments de réponse
Posté par gouttegd . En réponse au message ssh et chiffrement symétrique. Évalué à 6.
Il me semble que cette partie n’est pas correcte :
Cela sous-entend que la paire de clefs asymétriques du serveur est utilisé à la fois pour authentifier le serveur auprès du client, et pour chiffrer la clef de session (symétrique).
Je ne crois pas que ça se passe ainsi. La paire de clefs asymétriques est utilisé pour l’authentification uniquement. Une fois le serveur authentifié, le serveur et le client procèdent à un échange Diffie-Hellman pour obtenir tous les deux la clef de session symétrique ; cet échange n’implique pas la paire de clefs asymétriques du serveur.
C’est un détail qui a son importance, car cela implique qu’une éventuelle compromission ultérieure de la clef privée du serveur ne permettra pas de déchiffrer les clefs de session et donc de revenir déchiffrer le traffic enregistré (alors que ce serait possible si les clefs de session étaient directement chiffrées avec la clef publique du serveur).
Oui, un tel mécanisme existe. Le RFC 4253 suggère une telle re-négociation chaque fois qu’un giga-octets de données a été transféré, ou après chaque heure écoulée. Dans OpenSSH, ça se configure avec l’option
RekeyLimit.[^] # Re: Script sieve
Posté par gouttegd . En réponse au journal Chiffrement, chiche ?. Évalué à 5.
Pas de sources formelles malheureusement. Principalement un billet de Maître Eolas d’il y a quelques années à propos de « l’affaire Bourreau-Guggenheim » (cet employé de TF1 qui a été viré après que le message qu’il avait envoyé à son député, dans lequel il exposait une position contre HADOPI, avait été transmis à TF1 — le point de Maitre Eolas étant qu’il n’y avait rien de légalement répréhensible de la part du député qui a transmis le message).
Je cite Maître Eolas (lien ci-dessus) :
Bah non. Encore une fois, il est généralement mal vu de ne pas demander l’accord de l’émetteur (j’ai vu ça plusieurs fois dans des listes de discussion par exemple, où quelqu’un poste sur la liste des extraits d’un message qui n’avait été envoyé qu’à lui — il y a toujours au moins une personne qui interpelle « avez-vous demandé à M. Smith s’il était d’accord pour que ses propos se retrouvent sur une liste publique ? »), mais — en droit français du moins — ce n’est pas obligatoire.
Le fournisseur est un tiers, mais en signant chez lui le destinataire lui a donné l’autorisation de prendre connaissance du message. Certes, l’émetteur lui n’a pas donné cette autorisation, mais elle n’est pas requise si l’on admet que le destinataire a le droit de faire ce qu’il veut du message.
[^] # Re: Script sieve
Posté par gouttegd . En réponse au journal Chiffrement, chiche ?. Évalué à 10.
Bof, pas convaincu.
Depuis quand faut-il accepter les CGU du fournisseur de son interlocuteur ?
Ce que fait Gafam des messages que tu envoies à
jean.michu@gafam.exampleest l’affaire de Gafam et de Jean Michu uniquement.Je rappelle à toutes fins utiles que le destinataire d’un message est libre d’en faire ce que bon lui semble, indépendamment de ce que peut penser ou souhaiter son envoyeur. (Notamment, et contrairement à une idée qui semble répandue, le « secret des correspondances » ne lui est pas opposable. Le destinataire d’un message privé peut tout-à-fait le transmettre à un tiers ou même le rendre public — c’est souvent mal vu et considéré comme incorrect si on n’a pas l’accord express de l’expéditeur, mais ce n’est pas interdit.)
Du coup, si Jean Michu a décidé que ton message devait être traité par les services de Gafam, d’après moi c’est son droit le plus strict et je ne vois rien d’anormal à ce qu’on ne t’ait pas demandé ton avis.
À moins d’utiliser du chiffrement de bout-en-bout, n’importe quel fournisseur peut prendre connaissance du contenu de tes messages et des méta-données qui vont avec. Ce n’est pas parce que les GAFAM sont bien connus pour le faire qu’il faut s’imaginer qu’ils sont les seuls.
Si tu ne veux pas fournir des données privées au fournisseur de ton interlocuteur, tu chiffres, ou tu n’envois pas de données privées.
[^] # Re: Effets stochastiques des rayonnements ionisants
Posté par gouttegd . En réponse au journal j'ai testé... devenir radioactif. Évalué à 6.
Si. Je ne cherchais pas à te contredire.