Réunion des développeurs I2P - 1er février 2005

13:06 <jrandom> 0) salut 13:06 <jrandom> 1) état 0.5 13:06 <jrandom> 2) nntp 13:06 <jrandom> 3) propositions techniques 13:06 <jrandom> 4) ??? 13:06 <jrandom> 0) salut 13:06 * jrandom fait coucou 13:06 <+postman> salut jr 13:07 * postman fait coucou 13:07 <jrandom> w3wt il y a de la vie là-dehors :) 13:07 <jrandom> notes d'état hebdomadaires publiées @ http://i2p.net/pipermail/i2p/2005-February/000561.html 13:07 <ant> * dm fait coucou 13:08 <jrandom> pendant que vous lisez tous cet e-mail, on peut passer à 1) état 0.5 13:08 <MANCOM> salut 13:09 <jrandom> beaucoup de progrès la semaine dernière, toute la nouvelle crypto est intégrée et testée, et maintenant tout le fonctionnement des tunnels du router passe par les nouveaux pools de tunnels 13:10 <jrandom> il reste encore des parties du router que j'ai retirées pendant la mise à jour, comme l'intégration pour demander des leases aux clients ou tester périodiquement les tunnels, mais ça ne devrait pas être trop difficile 13:11 <jrandom> le code n'est pas compatible avec le réseau en production, et est sur une branche séparée dans cvs, donc les gens peuvent toujours récupérer le HEAD de cvs et travailler avec la dernière version 13:12 <+polecat> Dook j'ai finalement regardé cette page, et je ne comprends toujours pas comment on peut éviter la redondance à la mixmaster pour se protéger des attaques de détection de tunnel. 13:12 <+protokol> yey 13:12 <+polecat> J'imagine que ça marche très bien quand même. :) 13:12 <+protokol> tu ajoutes d'autres trucs sympas mais qui cassent la compatibilité ? 13:13 <+protokol> le pool de tunnels a un rapport avec les threads, non ? 13:13 <jrandom> polecat: on ne vérifie pas à chaque saut, mais on a une taille de message fixe pour empêcher un marquage utile (et tout est chiffré à chaque saut) 13:14 <jrandom> protokol: j'envisage http://www.i2p/todo#sessionTag 13:14 <+polecat> Alors comment empêcher plusieurs sauts de faire circuler de faux messages et de provoquer un DoS ? 13:15 <jrandom> mais non, les pools ne sont pas la question des threads, les pools nous permettent juste de gérer en toute sécurité les tunnels pour éviter ces messages « Lease expired » et pouvoir configurer la longueur par client 13:15 <jrandom> polecat: ils échoueront au point de terminaison, et le créateur détectera l'échec et passera à autre chose 13:16 <+protokol> jrandom: malgré les difficultés, je pense que toute fonctionnalité améliorant l'anonymat devrait être intégrée dès que possible 13:16 <+polecat> w00t ! PRNG synchronisé ! Première application que j'aie jamais vue de cette idée ! 13:17 <ant> <dm> que signifie PRNG ? 13:17 <ant> <dm> si je puis me permettre :) 13:18 <jrandom> protokol: d'accord, c'est à ça que sert 0.5 :) il n'y a pas d'autres fruits faciles au niveau de la couche I2P, mais il y a toujours des améliorations possibles aux couches appli et lib (par ex. filtrage i2ptunnel, etc.) 13:18 <jrandom> dm: générateur de nombres pseudo-aléatoires (PRNG) 13:18 <ant> <dm> cool, merci 13:20 <+protokol> donc tu dis qu'après ça, ce sera surtout des réglages de vitesse et de fiabilité ? 13:21 <+protokol> et pourquoi l'IRC est nul ces temps-ci 13:21 <jrandom> protokol: avant 2.0 pour le core et le router, oui 13:21 <+protokol> je n'arrive pas à me connecter au serveur de duck 13:21 <+protokol> yey 13:21 * jrandom ne sait pas, on a vu peut-être 5 déconnexions massives dans la dernière journée environ, peut-être quelque chose côté serveur 13:22 <jrandom> il y a toutefois beaucoup de choses à peaufiner, surtout dans la bibliothèque de streaming après le déploiement de 0.5 13:23 <+polecat> Cette histoire d'UDP. 13:24 <jrandom> ah, la bibliothèque de streaming ne devrait pas nécessiter de changements pour la version 0.6, au-delà de ceux que nous faisons pour la révision 0.5 13:25 <jrandom> ok, c'est tout ce que j'ai à dire concernant l'état 0.5 - quelqu'un a autre chose à ajouter dessus ? 13:27 <jrandom> sinon, passons à 2) nntp 13:27 <jrandom> nntp.fr.i2p est en ligne, allez voir :) 13:28 <jrandom> il ne semble pas que LonelyGuy soit dans le coin, mais on peut le joindre sur http://fr.i2p/. il y a aussi des instructions de configuration pour slrn sur mon blog, et jdot a constaté que thunderbird peut être assez sûr (quoique je ne sache pas quelle config jdot a utilisée) 13:30 <smeghead> LonelyGuy ? :) 13:30 <cervantes> quelqu'un a aussi testé Pan ? 13:30 <jrandom> il passe ici de temps en temps 13:30 <+polecat> je ne perdrais pas trop de temps sur nntp, mais tant qu'il y a un contrôle d'accès géré par l'utilisateur, ça va. 13:30 <jrandom> (lonelyguy, pas pan ;) 13:30 <smeghead> je pensais que son nom était LazyGuy 13:31 <jrandom> c'est LazyGuy ? 13:31 <jrandom> je sais qu'on a eu les deux... 13:31 <jrandom> tu as raison, lazyguy 13:31 * jrandom se poignarde ! 13:31 <jrandom> cervantes: je pense que LazyGuy l'a essayé, je ne connais pas la config ni le résultat toutefois 13:32 <cervantes> Je croyais que c'était LimeyGuy ? 13:33 * jrandom attend les commentaires de SnarkeyGuy 13:33 <smeghead> il est français 13:35 <jrandom> ok, je n'ai rien de plus à ajouter au-delà de ça, donc à moins que quelqu'un ait des questions, passons à 3) propositions techniques 13:35 <cervantes> smeghead: tu penses à ParesseuxGuy 13:36 <jrandom> orion a rassemblé de bonnes descriptions et idées pour quelques-uns des sujets les plus délicats sur 1) état 0.5 13:36 <jrandom> 2) nntp 13:36 <jrandom> 3) propositions techniques 13:36 <jrandom> erg 13:36 <jrandom> zut ^C^V 13:36 <jrandom> sur http://ugha.i2p/I2pRfc en fait 13:37 <jrandom> donc la prochaine fois que vous voudrez discuter de votre idée de nommage mortelle, allez sur http://ugha.i2p/I2pRfc/I2pRfc0001ResourceNameMetadata 13:39 <jrandom> je n'ai pas vraiment beaucoup plus à ajouter au-delà de ça. c'est un wiki, à vos contributions :) 13:39 <+polecat> Yay. 13:39 <+postman> jrandom: ohh, cool je pense que je dois en ajouter quelques-uns ... 13:40 <jrandom> cool postman, je m'en doutais :) il y a un modèle là-bas pour les nouveaux 13:41 <+postman> jrandom: laisse-moi un peu de temps (chaque chose en son temps) mais je contribuerai :) 13:41 <jrandom> w3rd 13:41 <+polecat> ResourceNameMetadata, le former est relativement trivial. L'astuce, c'est de comprendre comment /l'obtenir/ des autres. 13:42 <jrandom> polecat: comme l'a dit postman, chaque chose en son temps. 13:42 <+polecat> Mais si j'avais une solution, je serais en train de wikipédier, n'est-ce pas. :) 13:42 <jrandom> heh 13:42 <jrandom> discuter des compromis sur /comment/ distribuer avant de décider /quoi/ distribuer est prématuré 13:43 <jrandom> il y a de la place pour beaucoup d'idées cependant, donc que chacun se sente libre de poster des idées pas encore entièrement abouties (même si des idées pleinement fonctionnelles avec des implémentations seraient cool aussi ;) 13:44 <jrandom> ok, à moins qu'il y ait autre chose là-dessus, on peut peut-être passer au bon vieux 4) ??? 13:44 <jrandom> quelqu'un a autre chose à soulever ? 13:45 <jrandom> smeghead: y a-t-il quelque chose que les gens peuvent faire pour aider à résoudre les problèmes avec gcj, ou est-ce bloqué à cause de leur PRNG ? 13:46 <+polecat> Ce qu'il faut distribuer n'est qu'un dictionnaire signé. Aussi simple que ça. 13:46 <+polecat> Oui probablement une bonne idée. 13:46 <+polecat> Je travaille ENCORE sur le squelette de mon client bt i2p, mais j'apprécierais vraiment des conseils à n'importe quelle étape. 13:46 <smeghead> je pense que j'ai trouvé une solution 13:46 <smeghead> dans gnu crypto, il y a une implémentation Fortuna depuis l'été dernier 13:46 <jrandom> bien joué polecat 13:46 <jrandom> oh cool smeghead 13:46 <+polecat> smeghead: Hé, les 150 $ sont pratiquement à toi. 13:47 <smeghead> je peux bricoler un gnu-crypto.jar qui ne contient que les classes nécessaires pour Fortuna 13:47 <+polecat> Mes notes de travail jusqu'ici sont sur http://polecat.i2p/bittorrent.plan.doc 13:47 <smeghead> si on livrait le gnu-crypto.jar en entier, c'est environ 500 KB, vraiment trop gros 13:47 <+polecat> Ne laisse pas le .doc te faire peur, c'est en text/plain. 13:48 <+polecat> Fortuna n'utilise pas SecureRandom pour faire des choses aléatoires ? 13:48 <jrandom> ouh là, oui 500KB c'est un peu excessif, mais en jetant un œil à http://www.gnu.org/software/gnu-crypto/, ça ressemble à quelque chose qu'on pourrait intégrer sans risque (puisqu'on ne ferait que s'y lier, pas le modifier) 13:48 <smeghead> SecureRandom n'a jamais été le problème 13:48 <jrandom> polecat: fortuna /alimente/ secureRandom :) 13:49 <smeghead> jrandom: ce serait facile de faire un .jar personnalisé, probablement autour de 50KB 13:49 <smeghead> (estimation grossière hein) 13:49 <smeghead> je pourrais même faire un build ant pour le packager sur mesure à la demande 13:50 <jrandom> smeghead: tu veux l'intégrer dans i2p/apps/fortuna/ ? 13:50 <smeghead> je m'en occupe 13:50 <jrandom> génial ! 13:51 <smeghead> après ça, en supposant que gcj finisse par recracher des nombres aléatoires, il y aura probablement plus de tests de diverses fonctionnalités i2p 13:51 <+polecat> Quelle est la licence ? 13:51 <jrandom> on pourra alors faire un peu de vaudou dans net.i2p.util.RandomSource pour utiliser soit SecureRandom soit fortuna (si elle est trouvée, etc.) 13:51 <smeghead> lgpl 13:51 <+polecat> Cool. 13:51 <smeghead> vrai, SecureRandom serait inutile 13:52 <jrandom> oui, il reste encore beaucoup à faire pour le faire tourner sous gcj, mais c'est un excellent début 13:52 <jrandom> dans les profils que j'ai faits sur le réseau en production, le réensemencement du PRNG prend une bonne partie de la charge CPU 13:52 <smeghead> si quelqu'un aime écrire des tests 13:52 <smeghead> mais je n'ai probablement pas besoin de finir cette phrase 13:52 <jrandom> hehe 13:53 <smeghead> je vais demander au mainteneur de gnu crypto à propos de cette implémentation, parce que j'ai googlé des infos dessus et fouillé les archives de leur liste, et il n'y a pas un mot à ce sujet 13:54 <smeghead> et leurs journaux de commit cvs ne sont pas très éclairants non plus 13:54 <jrandom> 'k bonne idée 13:54 <smeghead> j'espère que ça marche 13:54 <smeghead> c'est dans le cvs de kaffe d'ailleurs 13:54 <smeghead> ta version devrait même l'avoir 13:55 <jrandom> hmm, ah, oui depuis l'import gnu-crypto 13:55 <smeghead> gnu.security.prng.Fortuna 13:55 <jrandom> le provider 'kaffe' utilise encore leur ancien sha1prng si je me souviens bien 13:55 <jrandom> cool 13:56 <MANCOM> quel est l'état des trucs SAM pour .NET ? faut-il commencer à s'y mettre ou faut-il s'attendre à des changements majeurs ? 13:56 <smeghead> MANCOM: il faut des tests, je vais écrire bientôt quelques tests unitaires 13:56 <smeghead> ce truc avec gcj a un peu mis ça en pause 13:57 <smeghead> MANCOM: je ne m'attends pas du tout à des changements de l'API, donc c'est sans risque de coder dessus 13:58 <smeghead> des changements derrière l'API sont probables, mais toi en tant que client n'as pas besoin de le savoir :) 13:59 <MANCOM> :) 13:59 <jrandom> il pourra y avoir plus tard des mises à jour pertinentes si tu construis des applis qui font de gros transferts en masse 14:00 <jrandom> mais si tu transfères juste des dizaines de Ko à la fois, ça ira 14:00 <smeghead> ok si l'API du client Java change, alors celle de sam-sharp changera aussi :) 14:01 <MANCOM> je ne peux pas dire le contraire 14:02 <jrandom> ok, quelqu'un a-t-il autre chose à aborder pour la réunion ? 14:02 * cervantes abaisse Big Ben dans le canal 14:03 <+DrWoo> note : beau travail jrandom 14:03 <smeghead> joli jeu de mots cervantes 14:03 * jrandom gémit 14:04 <MANCOM> j'ai lu que vous ne voulez pas trop faire de pub pour i2p avant la v0.5, est-ce vrai ? 14:04 <jrandom> MANCOM: avant 0.6. oui 14:04 <jrandom> MANCOM: 0.5 améliorera l'anonymat et aidera les utilisateurs à mieux contrôler leurs performances. 0.6 permettra à des milliers+ d'utilisateurs simultanés d'opérer en toute sécurité 14:04 <MANCOM> ah. 0.6. ok. 14:05 <jrandom> gracias doc, beaucoup de progrès :) 14:05 <+polecat> Youpi, vivement la 0.6... 14:05 <+DrWoo> :) 14:06 <jrandom> d'accord polecat, d'accord :) 14:06 * jrandom s'élance 14:06 * jrandom *baf* clôt la réunion