Il y a désormais plus de deux ans que le groupe de travail codec de l'IETF avait commencé un effort inédit de spécification d'un codec audio libre. Ce nouveau RFC, le 6716, est le couronnement de cet effort : Opus, le codec standard et libre est désormais officiel.
L'IETF avait créé en 2004 un groupe de travail nommé MARID, qui avait pour tâche de normaliser un mécanisme d'authentification faible du courrier électronique par le biais de la publication dans le DNS des serveurs autorisés à envoyer du courrier pour un domaine. Deux propositions étaient sur la table, SPF et Sender ID. Microsoft avait pratiqué une intense obstruction contre SPF, pour promouvoir sa propre solution, Sender ID. Six ans après est publié le RFC 6686 qui conclut enfin officiellement (...)
Ce RFC met officiellement fin à une amusante tradition, qui était un des charmes des protocoles TCP/IP mais qui, en pratique, a causé quelques ennuis, justifiant son abandon. Cette tradition concernait le nommage des paramètres dans les protocoles. Normalement, ces noms étaient enregistrés à l'IANA pour éviter des collisions (par exemple, il ne doit y avoir qu'un seul champ nommé User-Agent: dans une requête HTTP). Comme cet enregistrement nécessitait une procédure, parfois lente et lourde, cela contrariait les gens qui (...)
The Most Dangerous Code in the World : Validating SSL Certificates in Non-Browser Software par Martin Georgiev, Subodh Iyengar, Suman Jana, Rishita Anubhai, Dan Boneh et Vitaly Shmatikov
Une excellente étude sur les vulnérabilités des applications utilisant TLS (autrefois nommé SSL), à l’exclusion des navigateurs Web. Des tas d’applications parfois peu connues et discrètes (par exemple pour réaliser la mise à jour des logiciels d’un système) utilisent, comme les navigateurs Web, TLS pour se protéger contre un méchant qui essaierait (...)
Aujourd'hui, des millions d'utilisateurs innocents sous-traitent leur présence en ligne à des gros industriels du cloud comme Google ou Facebook. Cela, au détriment de leur vie privée et au prix d'une complète perte de contrôle de leurs propres données. L'alternative libre est évidemment l'auto-hébergement, avoir un jeu d'applications (libres) qui mettent en œuvre cette présence en ligne, sur une machine (Linux, évidemment) qu'on contrôle.
Mais tout le monde n'a pas forcément la compétence, ou tout simplement le temps ou l'envie, (...)
On trouve sur LinuxFr pas mal d'articles sur le Raspberry Pi, écrits avant sa livraison et essayant d'imaginer ce qu'on pourrait faire avec (par exemple https://linuxfr.org/news/le-raspberry-pi-est-arrive).
Mais je ne trouve pas d'articles écrits depuis où l'auteur raconte son expérience. On en trouve plein en anglais, peu en français et rien sur LinuxFr. Les LinuxFristes ne sont pas intéressés ? Ou bien sont-ils trop occupés à jouer avec leur Pi ? :-)
Linux se tire plutôt bien de cette amusante expérience.
La plupart des RFC décrivent, de façon normative, un protocole ou un format qui sera ensuite déployé sur l'Internet. Mais ce document est différent : c'est un récit d'expérience, celle de deux courageux chercheurs qui, au péril de leur usage de Facebook et dans l'intérêt de la science, ont coupé IPv4 et n'ont accédé à l'Internet que via IPv6 pendant la durée de l'expérience. Les machines de l'expérience n'avaient plus du (...)
La lutte contre le spam est un domaine où les certitudes (souvent assénées avec conviction) sont plus fortes que les faits. Prenez n'importe quel forum, en ligne ou ailleurs, où on discute des mesures qui pourraient limiter les conséquences du spam, vous y lirez et entendrez des affirmations radicales, par exemple sur l'efficacité du greylisting, sans que les affirmateurs ne se soucient d'appuyer leurs déclarations sur des mesures concrètes, faites dans la réalité. Comme le note le tout nouveau RFC (...)
Constatant l'absence d'un codec entièrement libre (pas plombé par des brevets, pas contrôlé par une société unique, implémentable en logiciel libre), l'IETF s'est lancée dans la spécification d'un codec satisfaisant. Le RFC 6366 donnait le cahier des charges technique du futur codec (le produit final) et ce nouveau RFC, le 6569, donne les considérations portant sur le processus de développement (processus déjà bien entamé) : méthodologie d'évaluation des propositions, mécanisme de vérification de la compatibilité des implémentations, questions de propriété intellectuelle. (...)
Il y a des tas de sortes d'identificateurs pour désigner les trucs (les choses, les objets, les ressources) qu'on récupère sur le réseau. Une technique amusante est que l'identificateur dépende du contenu de l'objet, ce qui permet de vérifier qu'on a récupéré le bon objet, quelle qu'était la source. C'est le cas des magnets de BitTorrent, par exemple :
http://fr.wikipedia.org/wiki/Magnet_(standard)
Freenet avait déjà montré la voie il y a bien longtemps, avec ses CHK (Content Hash Key).
Voici une nouvelle (...)
LISP (Locator/ID Separation Protocol) n'a rien à voir avec le langage de programmation du même nom. C'est un protocole de séparation de l'identificateur et du localisateur visant à résoudre le problème de la croissance de la taille des tables de routage sur l'Internet. Il est testé depuis des années mais les RFCs le décrivant viennent juste de sortir.
Le RFC principal est le 6830. Un résumé en français :
http://www.bortzmeyer.org/6830.html
Le site officiel des tests (notamment avec Facebook) : http://www.lisp4.net/
On le sait (cela a déjà été discuté ici, en http://linuxfr.org/users/beberking/journaux/le-cloud-computing-a-la-francaise ) le gouvernement français a un projet de « cloud souverain », c'est-à-dire d'une infrastructure informatique permettant de gérer un grand nombre de machines et de services sur une plate-forme distante, mais située en France, notamment pour des raisons de sécurité (en raison du Patriot Act, les machines d'Amazon, par exemple, peuvent être fouillées par le FBI à tout moment).
Ce projet se nommait Andromède puis, suite à des désaccords internes, (...)
Hier a vu la publication du premier « Rapport sur la résilience de l'Internet en France ».
Il s'agit d'étudier quantitativement la résilience de l'Internet dans ce pays (oui, je sais, l'Internet est mondial, mais il faut bien commencer quelque part). Le rapport définit donc un certain nombre d'indicateurs puis les mesure et publie le résultat.
Le rapport est un travail commun de l'ANSSI et de l'AFNIC. Il comprend deux grandes parties, une sur le protocole BGP et une sur (...)