Réunion des développeurs I2P - 22 novembre 2005

16:18 <jrandom> 0) salut 16:18 <jrandom> 1) Statut du réseau 16:18 <jrandom> 2) Chasse au renard 16:18 <jrandom> 3) ??? 16:18 <jrandom> 0) salut 16:18 * jrandom fait un signe de la main, en retard, depuis une maison où le courant est rétabli 16:18 <jrandom> les notes d'état hebdomadaires sont en ligne @ http://dev.i2p.net/pipermail/i2p/2005-November/001227.html 16:19 <jrandom> 1) Statut du réseau 16:20 <jrandom> pas grand-chose à ajouter au-delà de ce qu'il y a dans le mail.. quelqu'un a quelque chose à soulever concernant le statut du réseau ? 16:21 <jrandom> sinon, on passe à 2) Chasse au renard 16:21 <zzz> excellente idée 16:22 <jrandom> ici aussi, je n'ai pas grand-chose à ajouter au-delà de ce qu'il y a dans le mail et des propositions de Raccoon23... 16:22 <+fox> <ailouros> J'ai quelque chose contre le nom « Fox hunt ». Je préférerais l'appeler « Man hunt ». Les renards n'ont rien fait de mal. 16:22 <Raccoon23> hah 16:22 <jrandom> oui, je suis d'accord zzz, ce sera très utile pour donner aux gens une vraie motivation sans les dangers sérieux d'un usage réel 16:23 <nickless_head> appelez ça « chasse au <politically correct animal> » 16:23 <Raccoon23> « Fox hunt » est le nom typique d'un concours de radioamateur où l'on essaie de trouver un émetteur clandestin 16:24 <+fox> <ailouros> Je me fiche des émetteurs radio appelés Fox, on parle d'I2P ici, pas de renards anonymes autorisés 16:24 <+fox> <ailouros> :D 16:24 * cervantes se demande si ailouros connaît le nom de changate 16:24 <nickless_head> peut-être « Dissident hunt » 16:25 <@cervantes> <fox> <ailouros> :D 16:25 <+fox> <ailouros> (euh c'est quoi changate ?) 16:25 <jrandom> heh 16:25 <@cervantes> ailouros : c'est les bots qui relaient le chat entre différents réseaux 16:26 <+fox> <ailouros> tu veux dire vulpine ici ? 16:26 <@cervantes> le chat sur I2P t'est relayé sous le nom vulpine 16:26 <@cervantes> et ton chat nous est relayé via fox 16:26 <@cervantes> ;-) 16:26 <@cervantes> *ton 16:26 <+fox> <ailouros> alors la chasse vise le pauvre bot esclave corvéable ? :D 16:27 <Raccoon23> donc oui, je pense qu'il faudrait mettre en place une page prime/info. Je pense qu'on devrait viser à lever 1 000 $ 16:27 <+fox> <ailouros> ouais désolé, je ne vais pas d'habitude sur i2pchat :) 16:27 <+fox> <ailouros> ça, c'est une prime ! 16:28 <jrandom> Raccoon23 : je suis d'accord, mais c'est peut-être un peu prématuré de le faire maintenant. 16:28 <jrandom> (on peut toujours allouer des fonds du fonds général à la prime pour la lancer quand nécessaire) 16:28 <+fox> <ailouros> lancer la chasse tout de suite mais sans prime ? 16:28 <+fox> <ailouros> je veux dire, plus ça commence tôt, plus il y aura d'yeux ouverts 16:28 <jrandom> pour que la chasse au renard ait du sens (c.-à-d. qu'elle aide I2P), il faut le faire prudemment. 16:28 <jrandom> non ailouros, je ne suis pas d'accord. 16:29 <jrandom> lancer le concours avant qu'I2P soit prêt serait très mauvais. 16:29 <Raccoon23> ouais 16:29 <jrandom> à la fois parce que cela ferait perdre du temps aux gens à évaluer quelque chose qui n'est pas fini, et parce que ça n'apprendrait rien d'utile 16:30 <+fox> <ailouros> ....compris 16:30 <Raccoon23> et ce serait une mauvaise publicité si des vulnérabilités étaient « trouvées » alors qu'elles sont déjà prévues d'être corrigées dans les prochaines versions 16:30 <jrandom> oui 16:33 <jrandom> ok, autre chose pour le point 2), ou on passe au 3) ??? 16:34 <zzz> sur l'autre partie du fil jrandom/raccoon23, est-ce qu'on conclut qu'on passe à un minimum de 2 sauts ? d'autres conclusions ? 16:35 <jrandom> hmm, tout dépend de qui est l'adversaire, mais ça ne ferait pas vraiment de mal de mettre par défaut 2 +0-1 et cela offrirait une protection contre une certaine classe d'attaquants 16:35 <jrandom> autre conclusion possible : « hey, mettons-nous en route pour 0.6.2 » :) 16:35 <+fox> <ailouros> comment je règle la configuration pour que les tunnels aient toujours une valeur fixée (comme 0+1 de variance) ? Je retrouve les valeurs par défaut à chaque redémarrage 16:36 <jrandom> ailouros : tu devrais pouvoir enregistrer les paramètres sur /i2ptunnel/ 16:36 <jrandom> ou bien tu les changes sur /configtunnels.jsp ? 16:37 <Raccoon23> Je pense que des tunnels à 1 saut permettent à un attaquant assez faible d'en faire beaucoup, au moins en 0.6.1. Je plaiderais pour que 0.6.1.6 n'ait pas de tunnels à 1 saut par défaut 16:37 <+fox> <ailouros> donc c'est configtunnels 16:37 <jrandom> oui, d'accord Raccoon23 16:37 <jrandom> ailouros : utilise /i2ptunnel/ et enregistre tes paramètres 16:37 <+fox> <ailouros> je n'avais pas remarqué la nouvelle interface :D 16:38 <@cervantes> ailouros : vient d'être ajouté dans la 0.6.1.5 16:38 <jrandom> oui, cervantes a fait du super boulot là-dessus, ailouros 16:38 <+fox> <ailouros> eh bien, bravo pour ça 16:39 <@cervantes> tant qu'on y est, si des gens ont des problèmes pour enregistrer les paramètres avec la nouvelle interface, ils voudront peut-être utiliser un navigateur non-IE pour l'instant jusqu'à la prochaine version 16:39 <@cervantes> *grommelle* microsoft *grommelle* 16:40 <+fox> <ailouros> sur un autre sujet, est-ce que quelqu'un serait intéressé si je montais un serveur nethack sur I2P ? :D 16:41 <@frosk> ailouros : j'y pensais (je joue à nethack IRL), mais la latence serait horrible j'ai peur (et la latence c'est vraiment nul quand on joue à nethack) 16:42 <+fox> <ailouros> je suppose 16:42 <+fox> <ailouros> ok, idée abandonnée 16:43 * frosk vient juste d'avoir sa première ascension il y a quelques mois, woot 16:44 <jrandom> ok, quelqu'un a autre chose pour la réunion ? 16:45 <+fox> <ailouros> oui, un indicateur pour syndie quand le fil a un nouveau message 16:46 <nickless_head> jrandom : et ce serait cool si les nouveaux messages (les titres) pouvaient s'afficher en gras/italique la première fois qu'ils sont montrés 16:47 <nickless_head> jrandom : il y a une méthode vraiment simple pour accéder aux messages dans la base de données syndie, via http ? 16:47 <jrandom> ah oui ailouros/nickless_head, je pense à coder en couleur/mettre un drapeau sur la première colonne par date (par ex., les choses postées aujourd'hui ont un drapeau vif, hier un moins vif, etc). 16:47 <nickless_head> jrandom : de préférence dans quelque chose de propre et importable comme du xml 16:48 <jrandom> nickless_head: wget -R http://localhost:7657/syndie/archive/ 16:48 <nickless_head> s'il y en a un, je pourrais écrire un exporteur syndie vers nntp 16:48 <jrandom> oh, si tu veux exporter vers nntp, utilise rss to nntp 16:48 <nickless_head> jrandom : ok, je vais essayer :) 16:48 <nickless_head> jrandom : ça existe déjà ? ... mince. ;) 16:49 <jrandom> je pense aussi à ajouter des historiques de messages par utilisateur pour te permettre de marquer les messages comme lus/non lus, mais ça ne sera probablement pas dans la 0.6.1.6 (à moins que quelqu'un d'autre ne l'implémente :) 16:49 <jrandom> ou peut-être un nouveau filtre sur l'arborescence des fils — n'afficher que les messages postés depuis [today |v] 16:49 <jrandom> (ou hier, ou il y a 2 jours) 16:50 <jrandom> nickless_head : http://www.methodize.org/nntprss/ 16:50 <nickless_head> jrandom : merci 16:54 <jrandom> de rien 16:54 <Raccoon23> jrandom : donc il me faudra un moment avant de pouvoir l'implémenter (je veux d'abord terminer les routes restreintes), mais que penses-tu d'un garlic routing (technique de regroupement/chiffrement de messages propre à I2P) optionnel en 1024 bits pour les tunnels serveur sortants ? 16:54 <jrandom> surcoût énorme — O(données) est>>> O(tunnels). si on a déjà des problèmes avec O(tunnels) maintenant, il n'y a aucune chance d'espérer O(données) 16:55 <Raccoon23> on a toujours des problèmes de CPU ? mon router a été assez bas, mais je n'ai pas exactement une T1 ici.. 16:56 <jrandom> tout le monde n'a pas des p4 ;) 16:56 <jrandom> j'entends des rapports de 8-15 % d'utilisation sur des machines lentes, mais ça pique sévèrement en cas de congestion 16:56 <jrandom> (jusqu'à 100+%) 16:56 <+Complication> À propos de la consommation CPU : assez curieusement, Java sur Mandriva 10.1 consomme beaucoup moins que Java sur Mandriva 2006. 16:56 <Raccoon23> ouais, mais ceux qui ne l'ont pas n'ont probablement pas de T1 16:56 <Raccoon23> non plus :) 16:57 <+Complication> Les deux sont optimisés, 2006 a jbigi compilé localement. 16:57 <jrandom> bizarre Complication 16:57 <jrandom> mêmes révisions d'I2P ? 16:57 <+Complication> Sur 2006 (Celeron 2.4) Java peut monter à 20 %. 16:58 <+Complication> Sur 10.1 il ne monte pas au-dessus de 5 %. 16:58 <+Complication> (En général) 16:58 <+Complication> (en général==pas au démarrage) 16:58 <+Complication> Mêmes révisions. 16:58 <+Complication> Presque la même version de Java aussi (_04 contre _05) 16:59 <+Complication> Ça me rappelle que je devrais peaufiner les démons un peu plus. Peut-être que certains gênent Java. 16:59 <+Complication> D'une façon tordue que je n'arrive pas à comprendre. 17:00 <+Complication> Mais oui, le Cel 300 se sent nettement mieux. Ça pourrait être le MTU adaptatif 17:01 <jrandom> ah cool, oui, on a des trucs sympas en préparation :) 17:03 <+Complication> Je me demande s'il y aurait un moyen de contourner les problèmes de jbigi liés à libc sur certaines distros Linux ? 17:03 <jrandom> oui, carrément, il suffit de reconstruire tous les jbigi 17:03 <jrandom> (ce n'est pas libc, c'est libg++) 17:05 * Raccoon23 décide qu'il n'abandonne pas ses rêves de garlic routing, mais va attendre que les performances se stabilisent.. peut-être en 2.0 17:05 <+Complication> Oh, tu penses qu'une reconstruction propre aidera ? 17:05 <jrandom> Complication : oui, les erreurs de liaison jcpuid sont inutiles, puisque jcpuid est en fait juste un appel ASM (et n'aurait de toute façon pas dû être implémenté en c++ ;) 17:06 <jrandom> Raccoon23 : cool :) c'est quelque chose qu'on peut faire éventuellement aussi sur le réseau live, simplement en utilisant un type de message I2NP différent, en annonçant la capacité adéquate, et en filtrant là-dessus 17:06 <jrandom> (éventuellement) 17:07 <Raccoon23> comme un caps=S pour un CPU rapide ? ;) 17:08 <jrandom> et caps=I pour insane ;) 17:08 <jrandom> ok, quelqu'un a autre chose pour la réunion ? 17:08 <Raccoon23> haha 17:09 <Raccoon23> que penses-tu du palliatif consistant à partager des clés entre plusieurs tunnels ? trop peu de gain pour le travail ? 17:09 <jrandom> pourquoi cela serait-il mieux que d'avoir simplement plusieurs tunnels et d'envoyer le message via l'un des multiples tunnels ? 17:10 <jrandom> (et, euh, ce ne serait pas pire, du point de vue de la sécurité et de l'anonymat) 17:10 <Raccoon23> eh bien l'idée est que les nœuds ne puissent pas dire quel trafic faisait partie d'un tunnel, de sorte que si tu fais tourner i2phex et un eepsite, et que tu choisis les mêmes hôtes pour tes tunnels, le trafic des deux serait mélangé autant que les sauts peuvent le voir 17:11 <Raccoon23> ce qui devrait rendre les attaques temporelles plus difficiles 17:11 <jrandom> ah, aïe, oui. ça ajoute une capacité de corrélation vraiment mauvaise 17:11 <jrandom> c'est pourquoi nous sommes passés à des pools de tunnels par client en 0.4 17:11 <Raccoon23> explique ? 17:11 <jrandom> i2ptunnel permet aux gens de partager des pools, s'ils le veulent, en partageant la même destination 17:12 <jrandom> si des messages pour 2 clients passent dans un tunnel, tu sais que ces deux clients sont contrôlés par la même personne 17:12 <jrandom> s/clients/destinations/ 17:13 <Raccoon23> eh bien si les clés étaient partagées, les premiers sauts pourraient être mélangés, mais les leasesets seraient séparés.. 17:13 <Raccoon23> les premiers sauts étant de toute façon les plus dangereux pour les attaques temporelles 17:13 <jrandom> ça permettrait quand même un vecteur pour relier les deux destinations censées être non corrélables 17:14 <jrandom> on pourrait bidouiller pour, espérons-le, obfusquer la corrélation, mais elles resteraient intrinsèquement liées. ce n'est pas nécessaire, et c'est mauvais. 17:18 <Raccoon23> retour à rêver de caps=SI je suppose :) 17:19 <jrandom> bon. ok, quelqu'un a autre chose ? 17:20 * jrandom conclut 17:20 * jrandom *baf* la réunion est close