L'alternative elle existait déjà dans le standard dns depuis fort longtemps ;)
L'alternative avec TCP, oui, depuis le début, mais elle est coûteuse pour le serveur.
Ce qui est plus nouveau, c'est EDNS0 (http://www.bortzmeyer.org/2671.html), qui permet de faire sauter la limite des 512 octets, et qui n'a été massivement déployé que depuis quelques années.
La complexité par rapport à quoi ? La personne qui parle de complexité à propos d'OpenID n'a manifestement jamais essayé de comprendre Cardspace ou Shibboleth...
> mais il y a tout un tas de VCS propriétaires à côté desquels l'offre open-source à
> longtemps fait pâle figure.
Ah non merci, des outils dangereux (perte de données), non automatisables, stockant les données sous leur format (donc quand le serveur de licence est en panne, aucun moyen de les récupérer), des outils dont le seul avantage était le cliquodrome fourni avec ?
Le domaine des VCS est un domaine où l'avantage des logiciels libres est net.
Je me doutais que la discussion allait surtout consister en remarques du genre "ya aussi XYZ 1.0 qui est super bien" :-)
Il existe actuellement au moins une douzaine de VCS libres décentralisés. Monotone, darcs, tla 2, Bazaar-NG, Codeville, ArX, Fascist, svk, Mercurial, git/cogito... et j'en oublie.
Le but de mon exposé n'était pas de faire une présentation de tous ces logiciels, d'autant plus que la majorité aura disparu dans deux ans (comme tla qui était super à la mode il y a deux ans et déjà en cours d'oubli).
Je voulais au contraire sensibiliser les utilisateurs de CVS à l'existence d'autres outils, d'autres solutions. Ce n'est pas facile, surtout que le concept même de VCS décentralisé suscite des réactions aussi vigoureuses que le concept d'édition sans verrou de CVS il y a quinze ans.
Donc, vous comprendrez que je ne tienne pas compte des messages du genre "Ouais, XYZ 1.0, C top k00l" :-) Ils ne sont pas du genre à rassurer ceux qui craignent de quitter CVS.
> Certains MTA ajoutent des champs au mail permettant de savoir quel
> était le From de l'enveloppe. Avec Postfix, il semble que ce soit la
> premiere ligne des en-tetes :
> "From titi@toto.com Mon Sep 6 15:10:22 2004" par exemple.
Non, ce From sans : à la fin est spécifique au format "mbox" et dépend donc du MDA (procmail, local, deliver, etc), pas du MTA (Postfix, sendmail, etc). Si vous utilisez le format Maildir, vous ne l'aurez pas.
Quant cette information est mise dans un en-tête, c'est Return-Path:.
> Pour un système anti-spam, analyser les en-tetes du mail est
> beaucoup trop cher,
Ce n'est pas du tout une question de coût (SpamAssassin fait des analyses bien plus complexes), c'est simplement que le FROM de l'enveloppe n'a pas les mêmes propriétés que le From: des en-têtes. Il existe plusieurs identités dans le courrier et les différents protocoles ne vérifient pas les mêmes. Le SenderID actuellement en cours de discussion offrira le choix de l'identité à tester.
>Le sender-id se base sur authentification IP et les DNS, deux technologies >maintes fois critiquees et sujet a de nombreuse attaques
...
> Une bonne analyse ici des divers problemes du SENDER ID:
> http://www.esecurityplanet.com/views/article.php/3398431(...)
N'exagérons rien : il n'y a rien de commun entre la facilité d'une usurpation d'identité via le protocole SMTP et la facilité d'usurpation d'une adresse IP ou même d'une réponse DNS.
Dans le premier cas, c'est trivial et déjà largement mis en oeuvre.
Dans le deuxième, c'est d'un autre ordre de grandeur ! Les gens qui, comme l'auteur de l'article cité disent que c'est trivial n'ont manifestement jamais essayé.(Certaines bogues qui rendaient ces attaques possibles ont été bouchées depuis longtemps, les noyaux Unix ont des numéros de séquence TCP difficiles à deviner, BIND n'accepte plus les réponses martiennes, etc.)
> si il faut vraiment une solution technique, je suis plutot pour des solutions du > cote du cryptage/signature.
Ces solutions sont spécifiées et implémentées depuis dix ou quinze ans. Pourquoi ne sont-elles toujours pas déployées si elles sont si miraculeuses ?
L'article en question est entièrement bâti sur une "étude" de MXlogic, une boîte qui... vend des solutions anti-spam et qui a donc tout intérêt à débiner ses concurrents.
Les chiffres donnés ne correspondent pas à ce que l'on mesure, par exemple sur le banc de test SPF de l'AFNIC.
La discussion ayant montré beaucoup d'ignorance sur les techniques SPF et SenderID et "l'ignorance ne pouvant pas être pardonnée, seulement guérie" (Confucius), j'oublie toute modestie et j'attire l'attention sur mes documents : un article d'introduction à SPF et SenderID , visant un public non-technique et des transparents d'un cours plus technique.
> J'ai toujours trouvé ça énorme de donner comme ça des /48 à tout va.
Le RFC 3177 explique fort bien pourquoi. En résumé, c'est parce que toute autre méthode d'affectation nécessiterait une bureaucratie pour décider de la taille de l'affectation, taille qui pourrait être remise en cause à chaque changement de FAI.
Il est plus simple de donner un /48 sans discussion.
> Et un flicage ultra-simplifié. Une IP fixe et immuable par personne.
Bon, ça, c'est du baratin pur et simple, je l'ai déjà expliqué à Antoine mais, comme il s'obstine à propager la même légende, reprenons les faits :
1) Une (une seule et pas celle que j'utilise chez moi, par exemple) des méthodes d'affectation des adresses IPv6 utilise l'adresse MAC (celle de la carte Ethernet). Elle permet donc potentiellement de suivre une machine (pas une personne) à la trace, même lorsqu'elle change de FAI (mais pas lorsqu'elle change de carte Ethernet).
2) Si on n'aime pas cela, on peut toujours choisir un autre mode d'affectation. Il y en a un qui a les mêmes propriétés (automatique et sans état) et qui est décrite dans le RFC 3041 (et c'est l'option par défaut dans le noyau Linux).
> De même que la pénurie d'IPv4 sous moins de 10 ans est largement
> éxagérée.
La pénurie existe déjà : sinon, on n'aurait pas besoin d'autant d'employés dans les RIR (Regional Internet Registries, comme le RIPE-NCC) chargés d'examiner les justifications, et de les approuver ou de les rejeter.
Si un LIR demande aujourd'hui des adresses IPv4, il doit justifier chaque affectation (même un /28), avec paperasse à l'appui. Avec IPv6, une fois obtenue sa première allocation, il est tranquille. Ce n'est pas une pénurie, ça ? C'est même du rationnement.
[^] # EDNS0, pas TCP
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche IPv6 à la racine des DNS. Évalué à 2.
L'alternative avec TCP, oui, depuis le début, mais elle est coûteuse pour le serveur.
Ce qui est plus nouveau, c'est EDNS0 (http://www.bortzmeyer.org/2671.html), qui permet de faire sauter la limite des 512 octets, et qui n'a été massivement déployé que depuis quelques années.
# Complexe par rapport à quoi ?
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche OpenID 2.0 est arrivé. Évalué à 2.
[^] # Re: Personne n'y met vraiment du sien
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche Communiqué du RIPE sur IPv6. Évalué à 2.
Peut-être parce que ça ne rapporte rien à celui qui s'y met alors que le coût de ne pas s'y mettre est partagé par tous ? http://www.bortzmeyer.org/ipv6-et-l-echec-du-marche.html
[^] # Re: Diverses remarques
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche Conférence Parinux : Les nouveaux systèmes de gestion de version. Évalué à 2.
> longtemps fait pâle figure.
Ah non merci, des outils dangereux (perte de données), non automatisables, stockant les données sous leur format (donc quand le serveur de licence est en panne, aucun moyen de les récupérer), des outils dont le seul avantage était le cliquodrome fourni avec ?
Le domaine des VCS est un domaine où l'avantage des logiciels libres est net.
[^] # Re: Inscription
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche Conférence Parinux : Les nouveaux systèmes de gestion de version. Évalué à 2.
http://www.parinux.org/news/news-req.html?news=245
et je suppose (mais je ne suis pas à Parinux) qu'on peut venir informellement.
[^] # Re: Y'a aussi Bazaar 2
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche Conférence Parinux : Les nouveaux systèmes de gestion de version. Évalué à 8.
Il existe actuellement au moins une douzaine de VCS libres décentralisés. Monotone, darcs, tla 2, Bazaar-NG, Codeville, ArX, Fascist, svk, Mercurial, git/cogito... et j'en oublie.
Le but de mon exposé n'était pas de faire une présentation de tous ces logiciels, d'autant plus que la majorité aura disparu dans deux ans (comme tla qui était super à la mode il y a deux ans et déjà en cours d'oubli).
Je voulais au contraire sensibiliser les utilisateurs de CVS à l'existence d'autres outils, d'autres solutions. Ce n'est pas facile, surtout que le concept même de VCS décentralisé suscite des réactions aussi vigoureuses que le concept d'édition sans verrou de CVS il y a quinze ans.
Donc, vous comprendrez que je ne tienne pas compte des messages du genre "Ouais, XYZ 1.0, C top k00l" :-) Ils ne sont pas du genre à rassurer ceux qui craignent de quitter CVS.
[^] # Re: Explication
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche Technique anti-spam basée sur le « Sender ID » rejetée par Apache et Debian. Évalué à 1.
> était le From de l'enveloppe. Avec Postfix, il semble que ce soit la
> premiere ligne des en-tetes :
> "From titi@toto.com Mon Sep 6 15:10:22 2004" par exemple.
Non, ce From sans : à la fin est spécifique au format "mbox" et dépend donc du MDA (procmail, local, deliver, etc), pas du MTA (Postfix, sendmail, etc). Si vous utilisez le format Maildir, vous ne l'aurez pas.
Quant cette information est mise dans un en-tête, c'est Return-Path:.
> Pour un système anti-spam, analyser les en-tetes du mail est
> beaucoup trop cher,
Ce n'est pas du tout une question de coût (SpamAssassin fait des analyses bien plus complexes), c'est simplement que le FROM de l'enveloppe n'a pas les mêmes propriétés que le From: des en-têtes. Il existe plusieurs identités dans le courrier et les différents protocoles ne vérifient pas les mêmes. Le SenderID actuellement en cours de discussion offrira le choix de l'identité à tester.
[^] # Re: Deja inutile ?
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche Technique anti-spam basée sur le « Sender ID » rejetée par Apache et Debian. Évalué à 1.
...
> Une bonne analyse ici des divers problemes du SENDER ID:
> http://www.esecurityplanet.com/views/article.php/3398431(...)
N'exagérons rien : il n'y a rien de commun entre la facilité d'une usurpation d'identité via le protocole SMTP et la facilité d'usurpation d'une adresse IP ou même d'une réponse DNS.
Dans le premier cas, c'est trivial et déjà largement mis en oeuvre.
Dans le deuxième, c'est d'un autre ordre de grandeur ! Les gens qui, comme l'auteur de l'article cité disent que c'est trivial n'ont manifestement jamais essayé.(Certaines bogues qui rendaient ces attaques possibles ont été bouchées depuis longtemps, les noyaux Unix ont des numéros de séquence TCP difficiles à deviner, BIND n'accepte plus les réponses martiennes, etc.)
> si il faut vraiment une solution technique, je suis plutot pour des solutions du > cote du cryptage/signature.
Ces solutions sont spécifiées et implémentées depuis dix ou quinze ans. Pourquoi ne sont-elles toujours pas déployées si elles sont si miraculeuses ?
[^] # Re: Deja inutile ?
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche Technique anti-spam basée sur le « Sender ID » rejetée par Apache et Debian. Évalué à 1.
L'article en question est entièrement bâti sur une "étude" de MXlogic, une boîte qui... vend des solutions anti-spam et qui a donc tout intérêt à débiner ses concurrents.
Les chiffres donnés ne correspondent pas à ce que l'on mesure, par exemple sur le banc de test SPF de l'AFNIC.
# Introduction et transparents sur SPF et SenderID
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche Technique anti-spam basée sur le « Sender ID » rejetée par Apache et Debian. Évalué à 3.
http://www.generic-nic.net/formation/lmap/(...)
[^] # Re: À quand l'utilisation chez les FAI ?
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche L'ICANN valide IPv6. Évalué à 3.
Le RFC 3177 explique fort bien pourquoi. En résumé, c'est parce que toute autre méthode d'affectation nécessiterait une bureaucratie pour décider de la taille de l'affectation, taille qui pourrait être remise en cause à chaque changement de FAI.
Il est plus simple de donner un /48 sans discussion.
[^] # Re: Traçage
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche L'ICANN valide IPv6. Évalué à 2.
Bon, ça, c'est du baratin pur et simple, je l'ai déjà expliqué à Antoine mais, comme il s'obstine à propager la même légende, reprenons les faits :
1) Une (une seule et pas celle que j'utilise chez moi, par exemple) des méthodes d'affectation des adresses IPv6 utilise l'adresse MAC (celle de la carte Ethernet). Elle permet donc potentiellement de suivre une machine (pas une personne) à la trace, même lorsqu'elle change de FAI (mais pas lorsqu'elle change de carte Ethernet).
2) Si on n'aime pas cela, on peut toujours choisir un autre mode d'affectation. Il y en a un qui a les mêmes propriétés (automatique et sans état) et qui est décrite dans le RFC 3041 (et c'est l'option par défaut dans le noyau Linux).
[^] # Re: ne pas confondre ce qu'on pourrait faire et ce que l'on peut faire
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche L'ICANN valide IPv6. Évalué à 3.
> éxagérée.
La pénurie existe déjà : sinon, on n'aurait pas besoin d'autant d'employés dans les RIR (Regional Internet Registries, comme le RIPE-NCC) chargés d'examiner les justifications, et de les approuver ou de les rejeter.
Si un LIR demande aujourd'hui des adresses IPv4, il doit justifier chaque affectation (même un /28), avec paperasse à l'appui. Avec IPv6, une fois obtenue sa première allocation, il est tranquille. Ce n'est pas une pénurie, ça ? C'est même du rationnement.
[^] # Re: On va bien s'amuser!!!!!
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . En réponse à la dépêche L'ICANN valide IPv6. Évalué à 2.
Bien sûr que si : il y en a même quatre (cf. http://www.root-servers.org/(...)) mais l'ICANN ne les annonce pas.