Réunion des développeurs I2P - 25 octobre 2005

16:24 <jrandom> 0) salut 16:24 <jrandom> 1) Statut du réseau 16:24 <jrandom> 2) Intégration de Fortuna 16:24 <jrandom> 3) Statut GCJ 16:24 <jrandom> 4) i2psnark revient 16:24 <jrandom> 5) Plus sur l’amorçage 16:24 <jrandom> 6) Enquêtes sur le virus 16:24 <jrandom> 7) ??? 16:24 <jrandom> 0) salut 16:24 * jrandom salue de la main 16:24 <jrandom> notes d’état hebdomadaires publiées sur http://dev.i2p.net/pipermail/i2p/2005-October/001079.html 16:25 * susi23 renvoie un signe de la main 16:26 <jrandom> passons à 1) statut du réseau 16:26 <jrandom> comme je l’ai mentionné, pour l’instant ça paraît plutôt raisonnable. 16:26 <+fox> <Romster> ah une réunion, cool 16:27 <jrandom> de bonnes choses arrivent aussi, donc on aura une nouvelle release plus tard cette semaine 16:27 <jrandom> quelqu’un a quelque chose à soulever concernant 1) statut du réseau ? 16:27 <@cervantes> omg 7 points 16:27 <+legion> oui ça a l’air bien :-) 16:27 <jrandom> semaine chargée, cervantes :) 16:28 <@cervantes> ça ne peut être que bon 16:28 <+Complication> Ça fonctionne relativement bien, même dev.i2p - je peux même faire des checkouts CVS sans messages EOF. 16:28 <jrandom> nice :) 16:28 <+Complication> Les derniers devaient être des surcharges liées à la release. 16:28 <+Complication> Mais je ne peux pas l’affirmer. 16:28 <jrandom> dev.i2p tourne aussi sur le dernier code de build (-7), donc ça devrait, espérons-le, mieux performer qu’avant 16:29 <jrandom> s/dev.i2p/cvs.i2p (etc)/ 16:29 <+legion> forums.i2p semble aussi bien meilleur qu’avant :) 16:29 <@cervantes> *ahem* 16:29 <+fox> <Romster> est-ce que i2p est sûr pour laisser d’autres rejoindre etc. ? 16:29 <+Ragnarok> ok, maintenant je dois essayer ce miraculeux « cvs checkout qui marche du premier coup » 16:30 <+fox> <Romster> vu qu’il n’y a plus de limites connues maintenant 16:30 <@cervantes> c’est parce que tout le monde matraque i2p-list au lieu de poster sur le forum 16:30 <+legion> hmm tu es sûr, cervantes ? 16:30 <jrandom> Romster : eh bien, on a bien grandi ces derniers temps, mais on devrait attendre la bêta publique jusqu’à 0.6.2 16:30 <jrandom> heh cervantes ;) 16:30 <jrandom> chut Ragnarok, tu vas nous porter la poisse ! 16:31 <+Ragnarok> wow... c’est vrai. Je suis sans voix 16:31 <+fox> <Romster> ok jrandom 16:31 <jrandom> (j’ai les yeux qui piquent à cause du curry que mes coloc cuisinent en bas) 16:31 <jrandom> bien vu, Ragnarok 16:32 <+fox> <Romster> lol ça c’est du curry costaud 16:32 <jrandom> ok, s’il n’y a rien d’autre sur 1), passons rapidement à 2) intégration de Fortuna 16:32 <jrandom> (c’est clair, Romster) 16:32 <+fox> <shardy> youpi pour l’intégration de Fortuna ! 16:32 <+fox> <Romster> on passe au 2) :P 16:32 <+fox> <Romster> c’est quoi, Fortuna ? 16:32 <jrandom> heh je me doutais que ça te plairait, shardy :) 16:32 <+fox> <Romster> j’ai un peu décroché le mois dernier 16:32 <+Complication> Algo PRNG (générateur pseudo-aléatoire), si je me souviens. 16:33 <+Complication> À ce qu’ils écrivent, c’en est un bon, supposément. :P 16:34 * Complication ne connaît cependant rien de son fonctionnement interne 16:34 <jrandom> shardy : j’aimerais que tu puisses y jeter un œil à l’occasion 16:34 <+fox> <shardy> bien sûr 16:34 <+fox> <shardy> vous utilisez l’implémentation GNU ? 16:34 <jrandom> Romster/Complication : il y a des liens dans le mail 16:34 <jrandom> oui shardy - http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/core/java/src/gnu/crypto/prng/Fortuna.java 16:35 <jrandom> (intégré avec http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/core/java/src/net/i2p/util/FortunaRandomSource.java ) 16:36 <jrandom> on diffère toutefois de l’implémentation gnu-crypto pure, puisqu’on a déjà du code AES256 et SHA256 (de Cryptix et Bouncycastle, respectivement) 16:36 <jrandom> ok, bref, c’est cool, on bosse pour intégrer ce support depuis probablement un an 16:37 <jrandom> (l’intégration de fortuna était un des projets principaux qui ont poussé smeghead à construire « pants » ;) 16:37 <jrandom> si quelqu’un a des questions/commentaires/inquiétudes à ce sujet, n’hésitez pas à les renvoyer sur la liste 16:37 <jrandom> (ou par email, ou sur le forum, bien sûr) 16:38 <+fox> <Romster> oui où est smeghead, il n’est pas passé depuis un moment 16:38 <jrandom> smeghead est [redacted] en train de [redacted] 16:39 <jrandom> ok, passons à 3) statut GCJ 16:39 <jrandom> i2p fonctionne sur GCJ ! [w00t!] 16:39 <+susi23> beau boulot 16:39 <+legion> sucré 16:39 <jrandom> du moins, ça marche sur GCJ 4.0.2 sur linux 2.6.12. Je n’ai pas essayé d’autres plateformes 16:40 <jrandom> oui, les équipes GCJ et GNU Classpath ont fait des merveilles 16:40 <jrandom> c’était vraiment facile à builder, les anciennes classes à références statiques dont je me souvenais n’étaient pas nécessaires 16:41 <+Complication> Ce qui semble plutôt positif, vu l’ouverture moins que complète de Sun Java (en ce qui concerne la distribution, si je me souviens bien). 16:41 <jrandom> un makefile est livré avec I2P maintenant, mais par simplicité, je pense qu’on va probablement rester sur une distribution Java pur, au moins en priorité 16:41 <+susi23> (ensuite on essaie de le faire tourner sur J2ME ;) 16:42 <+fox> <Romster> GCJ pour remplacer la JVM de Sun> 16:42 <cat-a-puss> comment sont les performances avec GCJ ? 16:42 <jrandom> oui, bien que Sun soit entièrement ouvert, et on /pourrions/ distribuer leur JVM avec I2P, mais leur licence interdit de distribuer leur JVM comme outil à usage général 16:42 <jrandom> cat-a-puss : comparables 16:42 <jrandom> la plupart du travail lourd dans i2p est déjà fait par du code assembleur ;) 16:43 <+fox> <Romster> i2p fonctionnerait comment avec C#/mono avec cet ajout Java vers C# (j’ai oublié son nom) 16:43 <+fox> <Romster> je me souviens que jrandom et moi on l’avait essayé il y a longtemps 16:43 <jrandom> aucune idée. mais si ça marche avec gcj, ça pourrait marcher avec ikvm - le machin JVM de mono 16:44 <+Ragnarok> IKVM 16:44 <+Ragnarok> rien 16:44 <+fox> <Romster> ah c’est ça, ikvm 16:44 <+fox> <Romster> beaucoup de différences entre GCJ, IKVM et celui de Sun ? 16:45 <jrandom> je n’ai jamais utilisé ikvm 16:45 <+fox> <Romster> je suis sûr que tu l’as déjà fait avec mono une fois, ou c’était eclipse ? 16:45 <+fox> * Romster hausse les épaules 16:45 <jrandom> et i2p tel que livré ne supporte pas actuellement la router console, bien qu’il supporte le fonctionnement du router, i2ptunnel et sam 16:46 <+Ragnarok> qu’est-ce qui bloque la router console ? 16:47 <+susi23> xerces, si je me souviens bien 16:47 <jrandom> des trucs xerces. le xercesImpl livré avec i2p a des dépendances sur sun.* et quand j’ai naïvement essayé de glisser le dernier xerces, faire GCJ de ça et de jdom et rome et le reste de jetty foirait 16:47 <jrandom> il semble que le dernier xerces ait quelques exigences supplémentaires 16:48 <jrandom> (pour des fichiers JAR qu’on ne livre pas actuellement). cependant, je suis sûr qu’on peut mettre la main dessus 16:49 <+fox> <Romster> jrandom est bon pour traquer les problèmes :) 16:49 <jrandom> encore meilleur pour en créer 16:49 <+fox> * Romster va chercher un café 16:49 <jrandom> ok, autre chose sur 3) statut GCJ ? 16:49 <jrandom> ou on passe à 4) i2psnark 16:50 <jrandom> c’est comme si c’était fait 16:50 <jrandom> ok, i2psnark est de retour (yay) 16:51 <jrandom> je n’ai pas grand-chose à ajouter à ce qui est dans le mail... tu as quelque chose, Ragnarok ? 16:51 <+Ragnarok> nope 16:51 <+susi23> au sujet du frontend web 16:51 <+Ragnarok> plus de tests seraient bien, donc tout le monde devrait l’essayer :) 16:52 <+susi23> le supporter avec susibt ne devrait pas poser problème 16:52 <jrandom> ooh raconte-nous, susi23 :) 16:52 <jrandom> nice 16:52 <+fox> <jme___> question naïve, pourquoi passer du temps à supporter un vieux client bt alors que d’autres (azureus) supportent un client complet ? 16:52 <jrandom> jme___ : azureus est vraiment du tonnerre 16:52 <+susi23> une release majeure de susibt est prévue pour novembre :) 16:53 <jrandom> heh cool, susi23 16:53 <+Complication> Pour moi, Azureus semblait terriblement complexe. 16:53 <+Ragnarok> azureus c’est de la daube 16:53 <+susi23> pour moi, j’ai toujours besoin d’une solution headless (sans interface graphique) 16:53 <+Ragnarok> pour ne pas trop édulcorer 16:53 <+fox> <jme___> ok :) 16:53 <jrandom> jme___ : azureus est un peu lourd, mais c’est une excellente solution BT polyvalente 16:53 <+Complication> (je pourrais très bien finir par mal le configurer et entamer mon anonymat.) 16:54 <+fox> <jme___> ça a du sens, je voulais juste savoir 16:54 <+fox> <Romster> pour moi azerious n’a jamais bien marché, je suis passé à bitlord qui marche 16:54 <jrandom> je compte toujours aider à améliorer encore le plugin azneti2p avec l’équipe d’azureus, mais i2psnark m’a pris littéralement moins de 2 heures avant que je ne sois en train de « swarmer » des données 16:54 <+legion> Oui azureus est juste trop gros et compliqué pour i2p 16:54 <+Complication> Si le but est de livrer un client BT avec i2p, un client léger semble mieux. 16:54 <+fox> <Romster> principe KISS 16:54 <+Ragnarok> J’aime mieux le client officiel, mais i2psnark a l’avantage majeur d’être assez simple pour que je puisse hacker dessus 16:55 <+legion> le truc c’est que i2p n’a pas besoin d’un client bittorrent lourd 16:55 <jrandom> oui, le code est vraiment propre (avec un formatage gnu un peu bizarre ;) 16:55 <+Ragnarok> fichu gnu 16:55 <+Ragnarok> le pire style d’accolades qui soit 16:55 <jrandom> heh 16:55 <+fox> <Romster> heh un reformatteur de code :) 16:55 <+Ragnarok> jrandom ne me laisse pas :) 16:55 <+Ragnarok> enfin, pour de bonnes raisons 16:55 <+fox> <jme___> indépendance et simplicité sont des critères avec lesquels je suis complètement d’accord 16:56 <+fox> <Romster> y aura-t-il des options pour activer le programme bt-torrent sur chaque nœud i2p ? 16:56 <jrandom> oui, ce serait bien si on pouvait rétroporter multitorrent, la sélection des pièces et le web à la branche principale du snark de mjw 16:56 <+Ragnarok> plus c’est simple, plus il y a de chances que ce soit maintenu 16:56 <jrandom> exactement, Ragnarok 16:57 <+legion> oui, rétroporter ça serait top 16:57 <+fox> <Romster> en aparté, regardez le réseau KAD d’emule, je trouve ça plutôt malin. 16:57 <jrandom> Romster : il est désormais livré par défaut avec le build, mais une fois qu’on l’aura mis dans susibt, il sera dans la nav du haut avec le reste des clients 16:58 <+Ragnarok> il nous faut aussi livrer un créateur de .torrent, par contre. Et un tracker serait sympa. 16:58 <jrandom> oui, en fait, snark a les deux, je les ai juste désactivés parce que je ne voulais pas les maintenir :) 16:58 <+legion> hmm bon point, ragnarok 16:58 <jrandom> mais les remettre ne serait pas bien compliqué 16:59 <+Ragnarok> eh bien, le créateur de torrent au moins ne devrait pas être trop dur 16:59 <jrandom> il y a aussi un Tracker.java, et de la gestion dans le PeerAcceptor, mais j’ai jeté ce qui n’était pas nécessaire, donc il faudrait sans doute regarder du côté de http://klomp.org/snark/ pour ça 17:00 <jrandom> (et voir http://dev.i2p/~jrandom/snark_diff.txt pour les changements) 17:00 <+fox> <Romster> puisque snarik est de retour, il sera travaillé, hein :) 17:00 <+legion> en fait, pour un tracker, il vaudrait mieux trouver une solution distribuée 17:00 <+fox> <Romster> snark* 17:00 <jrandom> porter du code est plus facile que construire un nouveau tracker distribué, legion ;) 17:00 <+fox> <Romster> legion, tu rêves 17:00 <+legion> c’est vrai, oui 17:01 <jrandom> mais je ne serais pas opposé à intégrer une solution de tracker distribué propre, maintenue et respectueuse de l’anonymat :) 17:01 <+fox> <Romster> ça pourrait être greffé sur les eepsites ? 17:01 * jrandom voit passer un poney volant devant la fenêtre 17:01 <+Ragnarok> le client bt officiel a un tracker distribué basé sur Kademlia, mais évidemment ce n’est bon qu’en référence de conception 17:01 <+legion> une base pour commencer ;) 17:02 <+fox> <Romster> en fait kademlia = réseau KAD d’emule ? hmm, si c’est le cas KAD serait idéal pour un tracker mais l’amorçage est un problème 17:03 <+Ragnarok> ils sont basés sur le même algorithme, mais ils ne sont en rien compatibles 17:03 <+Ragnarok> compatibles, même 17:04 <+Ragnarok> faire quelque chose comme le KAD d’emule pour i2phex serait assez intéressant... 17:04 <+Ragnarok> bref, poneys volants 17:04 <jrandom> :) 17:04 <jrandom> (d’accord sur les deux points) 17:04 <jrandom> ok, autre chose sur 4) i2psnark ? 17:05 <+Ragnarok> tant qu’on a quelque chose pour faire des fichiers .torrent, les trackers existants vont bien 17:05 <jrandom> c’est un bon point - il y a du code commenté dans le main de Snark, je crois 17:05 <+legion> non je pense que les trackers existants ne vont pas bien :( 17:05 <jrandom> qu’est-ce qui ne va pas avec eux, legion ? 17:05 <cat-a-puss> ne donnez pas juste un fichier torrent aux utilisateurs non plus 17:05 <+legion> souvent des difficultés pour y accéder 17:06 <jrandom> hmm cat-a-puss ? oh, tu veux dire, il nous faut une interface web pour faire du swarm en transparence ? 17:06 <+legion> les sites se prennent des vagues de trafic 17:06 <jrandom> ah, ça c’est le problème d’i2p, espérons que 0.6.1.4 améliore ça 17:06 <jrandom> postman me disait qu’il recevait des tonnes de hits sur tracker.postman.i2p 17:06 <jrandom> j’ai oublié les chiffres 17:06 <cat-a-puss> Si on gère à la fois le code de swarm et le code pour obtenir le torrent au départ, autant rendre ça transparent pour l’utilisateur 17:07 <jrandom> orion.i2p/bt/ n’est pas vraiment utilisé par contre 17:07 <jrandom> (et tracker-fr semble animé) 17:07 <+susi23> avec susibt j’espère inclure le flux RSS des trackers, ainsi tu n’as plus besoin d’aller sur la page web des trackers et tu récupères les torrents automatiquement :) 17:07 <cat-a-puss> ça évite aussi de confondre un torrent i2p avec un non anonyme 17:07 <+fox> <jme___> le tracker http pour bt ne passe pas à l’échelle à cause d’un protocole mal conçu 17:07 <+fox> <Romster> router watchdog router bloqué, redémarrage dur, wtf 17:07 <+legion> voilà, c’est mon point : certains trackers se font inonder pendant que d’autres sont au repos 17:07 <jrandom> cat-a-puss : ah, oui j’aimerais intégrer des hooks de syndie dans susibt :) 17:07 <+fox> <jme___> c’est facile à corriger mais ça casse la compatibilité avec le protocole bt officiel 17:08 <+fox> <jme___> c’est la voie suivie par le tracker DHT 17:08 <jrandom> (et réciproquement, pour que les gens puissent facilement syndiquer des fichiers .torrent, etc.) 17:08 <+Complication> Romster : j’ai ça aussi, mais la machine en question est limite (300 MHz) 17:08 <+fox> <Romster> le tracker distribué est la solution aux trackers sous le marteau 17:08 <jrandom> legion : ça peut facilement se corriger en utilisant des trackers différents :) 17:08 <+fox> <Romster> DHT d’azerius 17:08 <jrandom> coder coûte cher, utiliser d’autres URLs ne coûte rien 17:08 <+legion> oui, mais les gens ne semblent pas le faire, si ? 17:09 <jrandom> mais oui, un tracker distribué serait génial. pas sur ma feuille de route ceci dit, mais si quelqu’un s’y met, ce serait la Classe. 17:09 <+Complication> En temps voulu... quelqu’un pourra sûrement faire du distribué aussi. 17:09 <+legion> Au lieu de poster des torrents sur des sites de tracker, ils pourraient poster un bith et les détails sur leur eepsite. 17:10 <jrandom> bith == hash ? 17:10 <+legion> oui, c’est pour bittorrent hash, ce n’est pas mon terme 17:10 <+Complication> Au début, toutefois... un client simple et solide, en Java, livré avec le router... peut résoudre pas mal de problèmes. (Peut-être même récupérer des mises à jour signées sans surcharger dev.i2p.) 17:11 <+legion> oui, ce serait super 17:11 <jrandom> oui, Complication 17:11 <+fox> <Romster> oui, des mises à jour par torrent 17:11 <+fox> <Romster> ok point suivant sur la liste :) 17:12 <jrandom> ok, 5) plus sur l’amorçage 17:12 <+legion> oui passons 17:12 <jrandom> plein de choses intéressantes sur la liste dernièrement, et pas question que je résume tout ici :) 17:12 <+fox> <Romster> amorçage de la base de données du router i2p ? 17:12 <jrandom> quelqu’un a des questions/commentaires/inquiétudes à discuter à propos du fil ? 17:12 <jrandom> Romster : vois la liste et/ou l’email 17:12 <+fox> * Romster doit lire cette liste 17:13 <jrandom> oui, il y a de bonnes choses dessus :) 17:13 <+fox> <Romster> j’ai été assez occupé dernièrement 17:13 <+Complication> 26 messages à lire, je ne peux pas encore commenter 17:13 <jrandom> pas encore de résultat final, mais on s’oriente vers une nouvelle façon de construire des tunnels pour 0.6.2 17:14 <+fox> <Romster> une nouvelle façon, il y a un défaut dans la méthode actuelle ? 17:14 <+fox> <Romster> défaut* 17:14 <jrandom> L’analyse de Michael montre que l’attaque n’est pas vraiment un problème maintenant, car il y a des attaques plus faciles sur les alternatives 17:14 <jrandom> lis la liste ;) 17:14 <+fox> <Romster> arg plus tard 17:14 <+fox> <Romster> c’est maintenant :) 17:15 <+fox> <Romster> normalement je dors à cette heure. 17:15 <+fox> <Romster> donc je suis rarement à une réunion 17:16 <cat-a-puss> peux-tu poster tes idées pour une nouvelle façon / façons existantes / refusées dans un email à la liste pour qu’on compare 17:16 <+fox> <Romster> donc c’est lié aux méthodes d’attaque et à la création de tunnel je suppose, sans avoir lu la liste encore 17:16 <cat-a-puss> (c’est pour Jrandom) 17:16 <jrandom> cat-a-puss : je ne suis pas sûr qu’on ait vraiment abouti à un résultat final 17:16 <+fox> <Romster> ce serait une idée, cat-a-puss 17:17 <+Complication> Romster : oui, c’était plus ou moins pour donner moins d’infos au point de terminaison d’un tunnel exploratoire en tant qu’attaquant potentiel 17:17 <jrandom> mais http://dev.i2p.net/pipermail/i2p/2005-October/001073.html est le dernier pour ce que je vois sortir de ta suggestion 17:17 <jrandom> enfin, pas moins d’influence - i2p est un free route mixnet - mais moins d’information 17:18 <+Complication> Oui, ce serait sans doute un terme plus correct 17:18 <jrandom> (l’URL ci-dessus est pleine d’agitation de bras, pas encore de crypto solide) 17:18 <+fox> <Romster> moins = mieux pour plus de robustesse contre les attaques, je vois où tu veux en venir 17:18 <jrandom> ((mais je pense que tout ça est faisable avec des techniques existantes) 17:19 <jrandom> Romster : voici un graphique de l’attaque de Michael contre l’algorithme actuel, avec l’axe X indiquant quel % du réseau est compromis - http://dev.i2p.net/~jrandom/fraction-of-attackers.webp 17:20 <jrandom> (une construction télescopique simple serait hors graphique avant d’atteindre x=200) 17:20 <jrandom> ((donc ce qu’on a aujourd’hui est littéralement des ordres de grandeur meilleur)) 17:20 <jrandom> mais on peut encore améliorer 17:21 <jrandom> il y a aussi l’alternative garlic routing 17:21 <jrandom> bref, oui, encore des choses à trancher, gardez un œil sur la liste :) 17:21 <+fox> <Romster> ok je lirai bien la liste plus tard 17:22 <+fox> <Romster> et voir si je peux penser à quelque chose à ajouter 17:22 <jrandom> cool 17:22 <cat-a-puss> la méthode télescopique « nouvelle » serait-elle assez rapide pour faire de la construction à la demande ? 17:22 <jrandom> je ne suis pas sûr qu’on veuille ça 17:22 <jrandom> c’est la question O(1) vs O(N) 17:23 <jrandom> la nouvelle technique permettrait de créer un tunnel sans utiliser les tunnels exploratoires, en laissant les tunnels exploratoires pour l’opération netDb 17:23 <jrandom> (et pour la création de tunnel exploratoire :) 17:24 <+fox> <Romster> hrmm vaudrait-il la peine d’embrouiller les attaquants en leur donnant plein de faux positifs, masquant ainsi la source réelle 17:24 <+legion> ça sonne bien :) 17:24 <+legion> je pense que ce genre d’embrouille serait bien 17:24 <cat-a-puss> jrandom : d’accord, je demandais si ce faisant ça accélérerait assez pour que parfois les derniers hops ne sachent pas qu’ils sont le dernier hop, comme discuté sur la liste. 17:25 <+fox> <Romster> des tunnels exploratoires pour collecter des références de router netDB ? 17:25 <jrandom> romster : nous sommes les hackers ;) mais oui, si les faux positifs submergeaient les vrais positifs, il faudrait un nombre d’attaques bien plus grand pour obtenir des données statistiquement significatives 17:26 <jrandom> hmm d’accord cat-a-puss, mais je ne vois pas en quoi ça accélérerait, ça nous ferait passer d’une topologie de tunnel O(1) à O(N) 17:26 <jrandom> ou que veux-tu dire par accélérer ? 17:26 <+fox> <Romster> et si ça se détectait ça pourrait se retirer et se taire un moment ? 17:26 <jrandom> utiliser la nouvelle technique réduirait certainement les créations de tunnel échouées 17:26 <+fox> <Romster> ou changer sa clé par erreur et continuer ou un truc heh 17:26 <jrandom> romster : ça vaudrait probablement le coup de creuser les mails pour revoir l’attaque ;) 17:27 <+fox> <Romster> oui après dormir 17:27 <+Complication> Romster : autant que je sache, c’est surtout une attaque passive, donc la cible ne peut pas détecter qu’elle se produit 17:27 <+fox> <Romster> et réparer le PC d’un ami que j’ai ici 17:27 <+fox> <Romster> ah je vois, Complication. 17:27 <cat-a-puss> jrandom : je ne parle pas du truc O(n). Je veux dire juste attendre pour construire un tunnel client jusqu’à ce qu’une appli en ait besoin, plutôt que de les laisser traîner tout le temps. 17:28 <+Complication> (mais je peux me tromper, et ces 26 derniers messages peuvent avoir des composantes actives) 17:28 <+fox> <Romster> une attaque passive à long terme trouverait-elle finalement la cible ? 17:28 <+fox> <Romster> je commenterai après avoir lu la liste 17:28 <jrandom> ah cat-a-puss, on va certainement améliorer le pool de tunnels pour 0.6.2. actuellement on ne construit le tunnel que quand on en a besoin (en se donnant un peu de temps au cas où la création échoue) 17:28 <+Complication> Romster : eh bien, faire persister l’attaque au-delà de la durée de vie du tunnel demanderait des ressources et de la patience 17:28 <+fox> <Romster> et mieux comprendre 17:29 <+Complication> Mais le temps joue un rôle dans toute probabilité de succès. Plus tu tentes longtemps, plus tu as de chances. 17:29 <+fox> <Romster> ah l’idée est que la durée de vie du tunnel soit trop courte pour qu’une attaque valable marche réellement. 17:29 <jrandom> chaque pool a un nombre défini de tunnels de secours, et par défaut on construit les remplaçants entre 60 et 120 secondes avant qu’un ancien n’expire 17:29 <+fox> <Romster> temps* 17:30 <jrandom> exact, Complication - chaque échantillon n’apparaît que ‘m’ fois tous les (c/n) tunnels 17:30 <+fox> <Romster> il n’y a pas d’interaction entre chaque tunnel pour collecter des statistiques ? 17:30 <+fox> <Romster> quand l’un est sur le point de mourir et qu’un autre est en construction 17:31 <jrandom> romster : les nouveaux tunnels ne se parlent pas entre eux, non, mais ce n’est pas l’attaque que Michael a décrite 17:31 <jrandom> il y a d’innombrables attaques possibles, dont la plupart sont traitées, mais quand quelqu’un en propose une qui peut concerner le fonctionnement d’I2P, on veut l’analyser plus en profondeur 17:31 <+fox> <Romster> je dois lire la liste, ok je m’arrête là pour l’instant, quelqu’un d’autre a quelque chose à dire ? 17:32 <jrandom> ok, s’il n’y a rien d’autre, passons à 6) enquêtes sur le virus 17:32 <+fox> <Romster> en fait une stat qu’on peut voir être collectée est pas de 0 hop voudrait dire que le prochain hop n’est pas le point final donc on pourrait l’écarter mais avec des millions de nœuds cette technique d’analyse serait inutile 17:33 <jrandom> Je n’ai rien à ajouter au-delà de ce qui a été discuté sur le forum 17:33 <jrandom> oui Romster, il y a des attaques de prédécesseur sur la longueur des tunnels, ce qui est une des principales choses qu’on traite en 0.6.2 17:33 <+fox> <Romster> virus, quel virus, si c’est linux il sera inexistant, mais windows hmmm 17:34 <+Complication> Eh bien, même si je n’ai pas pu builder un binaire identique (allez savoir pourquoi) la différence finale était assez petite... pour être utile, j’espère, à qui veut lire du code assembleur. 17:34 <jrandom> Romster : s’il te plaît, les notes d’état hebdo devraient expliquer ces points de l’agenda, et la réunion est là pour discuter des choses /au-delà/ de ce qui est dans les notes ;) 17:35 <+Complication> Je n’ai rien trouvé d’évident dedans, mais je n’ai pas non plus pu expliquer toute la différence. 17:35 <@cervantes> rtfml et rtff 17:35 <+fox> <Romster> oui je ne suis pas à jour depuis un moment, désolé pour ça jrandom 17:35 <@cervantes> ;-) 17:35 <jrandom> oui, le fait qu’un fichier bat connu comme sûr et l’ancien déclenchent le même code de détection est significatif 17:35 <+Complication> Oui, ça enlève des doutes. 17:36 <+Complication> Je suppose que le QBFC peut avoir des différences non documentées pour le même numéro de version (builds différentes ?) 17:37 * jrandom n’en a aucune idée, mais c’est peut-être juste une interaction avec l’OS, ou autre. Je ne sais pas, tu as mis assez d’analyse pour que chacun se fasse une opinion informée 17:37 <+Complication> Je pense que c’est mieux comme ça. 17:37 <+Complication> La désassemblage est vraiment bien en dehors de mon terrain habituel. 17:37 <jrandom> legion : tu veux mentionner quelque chose à ce sujet, ou les gens devraient juste parcourir le forum s’ils veulent plus d’infos ? 17:38 <@cervantes> puis-je juste redire ce que d’autres ont dit sur le forum, et remercier Complication pour le temps et les tentatives méticuleuses qu’il a consacrées à vérifier ce problème 17:38 <jrandom> oui, c’est très apprécié 17:38 <+legion> Je n’ai rien à ajouter, j’ai l’impression d’en avoir déjà trop dit 17:39 <jrandom> d’accord compris. ok, quelqu’un d’autre a quelque chose à ajouter là-dessus, ou on passe à 7) ??? 17:39 <jrandom> [considérez que c’est fait] 17:40 <+fox> * Romster approuve aussi :) 17:40 <+legion> ok pour 7) ??? si on prenait un moment pour parler d’i2phex 17:40 <jrandom> cool, bonne idée 17:40 <+fox> <Romster> puisque je l’utilise en ce moment même :) 17:40 <@cervantes> non non câlin collectif d’abord 17:40 <jrandom> redzara a dit qu’il serait à la réunion, mais la progression sur la fusion est lente 17:41 <+legion> susi23 a demandé une version headless 17:41 <jrandom> ah cool, j’ai vu ton post là-dessus 17:41 <+fox> <Romster> puis-je ajouter que la liste des favoris doit être plus large pour gérer les clés i2p plus longues 17:42 <+susi23> (ce n’est pas indispensable, j’étais juste curieux) 17:42 <jrandom> eh bien, personne ne peut retenir des clés base64, donc je ne suis pas sûr que tu loupes grand-chose, Romster ;) 17:42 <jrandom> (et les premiers octets devraient suffire à les identifier de façon unique) 17:42 <+fox> <Romster> démarrer i2phex avec un serveur est le gros problème que je vois pour l’instant 17:42 <+legion> En fait j’aimerais n’afficher que les 12 premiers caractères des clés dans le client 17:42 <+fox> <Romster> heh devine 17:42 * Complication est malheureusement très occupé, et ne peut pas faire d’xml-rpc 17:43 <jrandom> ça semble raisonnable, legion 17:43 <+fox> <Romster> et si on affichait autant de caractères que nécessaire pour rendre la clé unique 17:43 <jnymo_> J’ai de bons résultats avec i2phex 17:44 <jrandom> cool jnymo_, j’ai entendu de bonnes choses aussi 17:44 <+fox> <Romster> donc si 2 clés commencent par abc ce sera abcx 17:44 <jnymo_> 12 caractères identiques, c’est peu probable, romster 17:44 <+fox> <Romster> vrai 17:44 <+Complication> En plus, plus simple = plus rapide 17:44 <+fox> <Romster> mais il n’aurait pas besoin de 12 si les clés sont suffisamment randomisées 17:45 <+Complication> (pas qu’il y ait beaucoup à gagner en vitesse sur l’affichage) 17:45 <+legion> Peut-être une nouvelle fenêtre de propriétés d’hôte, indiquant la clé complète et certaines infos comme combien il partage et autres 17:45 <+susi23> (netDb marche très bien avec seulement 4 caractères pour les IDs de router) 17:45 <+fox> <Romster> ou la base de données utilisant keyname=base64 et n’afficher que le keyname 17:45 <jrandom> hmm, je pensais qu’il y avait déjà un affichage d’info pair, legion ? 17:46 <jrandom> legion : certaines choses comme ça seraient sans doute bien à ajouter à la branche principale de phex ? 17:46 <+legion> hmm possible... 17:46 <jrandom> (comme ça Gregor peut le maintenir ;) 17:46 <+Complication> Eh bien, il y a une fonction « Browse host », mais ce n’est peut-être pas exactement la même chose. (Si ça marche.) 17:46 <jrandom> Complication : ça marche 17:46 <jrandom> (ça marche, donc) 17:47 <+Complication> Ça semble en gros mettre la destkey de l’hôte dans la boîte de recherche 17:47 <+Complication> ...et lancer une recherche. 17:48 <jnymo_> c’est peut-être un souci de la branche principale i2phex, mais je n’ai pas vu de date prévue pour les téléchargements i2phex 17:48 <+Complication> Hmm... ou en fait, ça ne lance pas de recherche. 17:48 <+Complication> Le mien semble attendre que je la lance manuellement. 17:48 <+fox> <Romster> à quoi sert la case à cocher « nearby i2phex running » ? 17:49 <+legion> Je vois qu’il y a de la marge pour des améliorations. ;) 17:49 <jrandom> yep :) 17:50 <jrandom> beaucoup à faire, et le forum est un bon endroit pour poster des idées/suggestions/questions(/patches :) 17:50 <+fox> <Romster> malgré son nom évident 17:50 <jrandom> ok, quelqu’un a autre chose pour la réunion ? 17:50 <+fox> <Romster> hmm bon point 17:50 <+fox> <Romster> je ne pense à rien d’autre 17:51 <+fox> <Romster> mais quelqu’un travaille-t-il sur un data store distribué ? 17:51 * cervantes regarde sa montre 17:51 <+fox> <Romster> genre activement 17:51 <jrandom> Romster : au-delà de syndie, non 17:51 <jrandom> (pas à ma connaissance, au moins) 17:52 <+legion> je me demandais s’il ne serait pas possible d’intégrer un gestionnaire de téléchargements http dans i2p, ça faciliterait le download de contenu plus gros depuis des eepsites. 17:52 <+fox> <Romster> q et iphex et un ou deux autres mais je n’ai rien vu de maintenu depuis un moment 17:52 <@cervantes> quel est le statut de feedspace... je n’en ai pas entendu parler depuis un moment 17:52 <jrandom> legion : ce serait cool - il y a un post à ce sujet sur le forum aussi je crois 17:53 <+fox> <Romster> ah feedspace, encore un 17:53 <jnymo_> si ça a déjà été mentionné à la réunion, ok.. mais, des nouvelles sur la collab i2p freenet ? 17:53 <jrandom> cervantes : la dernière fois que j’ai entendu, frosk était assez occupé, mais si frosk est là, peut-être qu’il peut nous en dire plus :) 17:53 <+legion> Personnellement j’aimerais voir une collab d’entropy avec i2p. 17:54 <+fox> <Romster> j’ai des idées pour un data store, mais ce serait une extension des méthodes existantes actuellement utilisées 17:54 <+legion> Étant donné que q, feedspace et consorts ne semblent pas aller très loin en ce moment 17:54 <jrandom> jnymo_ : j’ai envoyé aux gens de freenet du code pour tourner sur notre transport SSU, toad a participé à certaines discussions, mais freenet ne sera pas en position pour qu’on l’exécute comme data store au-dessus d’i2p avant un moment (après leur release 0.7, très probablement) 17:54 <+fox> <Romster> je veux démarrer un projet mais sans refaire ce que d’autres ont déjà fait 17:54 <+legion> je me demande s’il serait possible de porter entropy pour tourner sur i2p... 17:54 <jrandom> legion : entropy serait bien, mais l’intégration est plutôt difficile. bien sûr, on pourrait faire tourner des choses comme fproxy.i2p pour entropy 17:55 * jrandom ne connaît pas du tout le code de transport d’entropy 17:55 <+fox> <Romster> j’ai mis mon client irc en pause, il y en a déjà beaucoup en cours, tout ce qu’i2p a besoin maintenant c’est d’un data store et il battra freenet facilement :) 17:55 <jrandom> (mais peut-être que ce serait une bonne façon d’amener quelqu’un à hacker sur le SDK GCJ :) 17:56 <jrandom> Romster : aider sur d’autres efforts est beaucoup plus gratifiant que de commencer des projets tout neufs, on en fait beaucoup plus avec moins d’efforts :) 17:56 <jnymo_> ah.. bravo pour le port gcj 17:56 <+fox> <Romster> entropy est en c ou C++ iirc 17:57 <jrandom> oui Romster, ce qui fait qu’ils pourraient utiliser le SDK d’I2P et la bibliothèque de streaming, compilés avec GCJ en bibliothèques natives 17:57 <+fox> <Romster> jrandom c’est vrai, mais qui :) 17:57 <jrandom> pas moi 17:57 <+legion> oh et sur un autre sujet, juste pour mentionner qu’aujourd’hui j’ai sorti une nouvelle version de ma mise à jour de readme.html pour la router console i2p. 17:57 <jrandom> (la seule façon d’obtenir ce qui te tient à cœur, c’est que *toi* tu le fasses :) 17:57 <jrandom> cool 17:57 * dust aimerait voir une sorte de « squid » de syndication pour décharger les eepsites 17:58 <jrandom> dust : oui totalement, si on peut amener sucker à cette position, ce serait l’idéal 17:58 <jrandom> par ex. j’adorerais avoir les dernières infos d’orion dans syndie, en local 17:58 <+fox> <Romster> construire un proxy pour que squid l’utilise :) 17:59 <+legion> Je repoussais ça en espérant que certaines améliorations au python eepsitechecker auraient été faites d’ici là. 17:59 <dust> ah, syndie 17:59 <jrandom> (c’est justement l’objectif de syndie - la syndication pour réduire la charge) 17:59 <dust> _la_ réponse 17:59 <jrandom> il y a un eepsite checker python ? 17:59 <+fox> <Romster> c’est la première fois que j’en entends parler 17:59 <+legion> oui, c’est ce que j’utilise ;) 18:00 <jrandom> cool, legion 18:00 <+legion> vraiment ? Ça existe depuis un moment 18:00 <+fox> <Romster> sympa, j’aimerais voir ça :) 18:00 <@cervantes> je crois que quelqu’un a porté le script de baffled... je ne me souviens plus qui/quand 18:00 <+fox> <Romster> j’apprends python 18:00 <jrandom> ah ok cervantes 18:00 <+fox> <Romster> à la dure, par les exemples et le manuel :) 18:00 <jrandom> oui, je suis feignant, j’utilise juste polecat.i2p/i2psurvey/ et orion.i2p/ :) 18:01 <jrandom> (pas besoin pour moi de crawler) 18:01 <+legion> si quelqu’un veut bien bosser avec moi dessus, j’aimerais beaucoup corriger le code et le faire marcher avec python 2.3 ou 2.4 18:01 <+fox> <Romster> j’ai la 2.4 installée ici 18:01 <+Ragnarok> Je peux y jeter un œil. Un lien ? 18:01 <+fox> <Romster> je crois même que c’est 2.4.1 18:02 <+legion> pour l’instant il n’a pas de compatibilité py2exe et la moitié marche avec chaque version, ce qui veut dire que quiconque le lance doit avoir les deux installées. 18:02 * jnymo_ adorerait voir un hybride orion.i2p/I2PDirectory.. infos, catégories, stats.. aux petits oignons 18:02 <+legion> Je l’archiverai après la réunion et je posterai un lien sur les forums 18:03 <+Ragnarok> ok 18:03 <jrandom> legion : hmm, tu vois beaucoup de gens en avoir besoin ? Je veux dire, seuls quelques-uns ont besoin de crawler 18:03 <+fox> <Romster> les deux berk, c’est peut-être un peu trop pour que je traduise vers la plus récente, je ne sais pas tant que je n’ai pas vu le code 18:03 <jrandom> (non pas qu’il y ait un problème à faciliter la vie de ces quelques personnes, hein :) 18:04 <+fox> <Romster> ça pourrait être disséqué et servir à faire d’autres choses aussi ? 18:04 <+legion> En fait je vois des usages possibles pour tous ceux qui font tourner i2p. 18:04 <+fox> <Romster> pourrait* 18:04 <jrandom> hmm, je ne suis pas sûr, tu peux expliquer comment ? 18:04 <jrandom> Je ne veux pas que tout le monde fasse en gros un DDoS sur chaque eepsite 18:05 <+legion> L’un d’eux serait une page de marque-pages dynamique, auto-générée toutes les 12-24 heures environ. 18:05 <jrandom> ah, c’est trivial dans syndie (en fait une des fonctionnalités principales - « nouveaux blogs ») 18:05 <jrandom> ((mais bien sûr, syndie n’a pas encore une super UI pour ça)) 18:06 <+fox> <Romster> en fait seuls quelques-uns auraient besoin de crawler et d’envoyer ça dans une base de type torrent/dht et de synchroniser ça entre les nœuds 18:06 <jrandom> oui Romster (bien que cette base de type torrent/DHT pour synchroniser, ou « syndi »quer, pourrait être syndie ;) 18:06 <+fox> <Romster> ça pourrait même être un moyen caché d’apprendre plus de nœuds et de services i2p 18:07 <+fox> <Romster> oui ou syndie 18:07 <jrandom> ok, quelqu’un a autre chose pour la réunion ? le curry refroidit ;) 18:08 <+fox> <Romster> si syndie est aussi bien, on pourrait stocker des pages statiques en cache et pareil pour les images 18:08 <+fox> <reliver> bon appétit, jrandom :-) 18:08 <jrandom> exactement, romster, tu peux déjà le faire 18:09 <jrandom> ok, s’il n’y a rien d’autre... 18:09 * jrandom conclut 18:09 * jrandom *baf* clôt la réunion