Reunión de desarrolladores de I2P - 25 de octubre de 2005

16:24 <jrandom> 0) hola 16:24 <jrandom> 1) Estado de la red 16:24 <jrandom> 2) Integración de Fortuna 16:24 <jrandom> 3) Estado de GCJ 16:24 <jrandom> 4) i2psnark regresa 16:24 <jrandom> 5) Más sobre el bootstrapping (proceso inicial de incorporación) 16:24 <jrandom> 6) Investigaciones sobre virus 16:24 <jrandom> 7) ??? 16:24 <jrandom> 0) hola 16:24 * jrandom saluda 16:24 <jrandom> notas de estado semanales publicadas en http://dev.i2p.net/pipermail/i2p/2005-October/001079.html 16:25 * susi23 saluda de vuelta 16:26 <jrandom> vamos a pasar a 1) estado de la red 16:26 <jrandom> como mencioné, las cosas se ven bastante razonables hasta ahora. 16:26 <+fox> <Romster> ah, reunión, qué bien 16:27 <jrandom> también vienen cosas buenas en camino, así que tendremos una nueva versión a finales de esta semana 16:27 <jrandom> ¿alguien tiene algo que quiera comentar sobre 1) estado de la red? 16:27 <@cervantes> omg 7 temas 16:27 <+legion> sí, pinta bien :-) 16:27 <jrandom> semana ocupada, cervantes :) 16:28 <@cervantes> solo puede ser bueno 16:28 <+Complication> Funciona relativamente bien, incluso dev.i2p: puedo hacer checkouts de CVS sin mensajes de EOF. 16:28 <jrandom> bien :) 16:28 <+Complication> Puede que las últimas saturaciones estuvieran relacionadas con la versión. 16:28 <+Complication> Pero no puedo asegurarlo. 16:28 <jrandom> dev.i2p también está en el código de la última build (-7), así que con suerte rendirá sustancialmente mejor que antes 16:29 <jrandom> s/dev.i2p/cvs.i2p (etc)/ 16:29 <+legion> forums.i2p también parece estar mucho mejor que antes :) 16:29 <@cervantes> *ejem* 16:29 <+fox> <Romster> ¿es i2p seguro para dejar que otros se unan, etc.? 16:29 <+Ragnarok> ok, ahora tengo que probar este milagroso «cvs checkout que funciona a la primera» 16:30 <+fox> <Romster> ya que ahora no hay límites conocidos 16:30 <@cervantes> eso es porque todos están machacando i2p-list en lugar de publicar en el foro 16:30 <+legion> hmm ¿seguro, cervantes? 16:30 <jrandom> Romster: bueno, hemos estado creciendo a buen ritmo últimamente, pero deberíamos posponer la beta pública hasta la 0.6.2 16:30 <jrandom> je, cervantes ;) 16:30 <jrandom> shhh, Ragnarok, ¡lo vas a gafar! 16:31 <+Ragnarok> wow... es verdad. Me dejas sin palabras 16:31 <+fox> <Romster> ok, jrandom 16:31 <jrandom> (uf, se me llenan los ojos de lágrimas por el curry que mis compañeros están cocinando abajo) 16:31 <jrandom> bien ahí, Ragnarok 16:32 <+fox> <Romster> lol, eso sí que es un curry fuerte 16:32 <jrandom> ok, si no hay nada más sobre 1), podemos pasar rápidamente a 2) Integración de Fortuna 16:32 <jrandom> (cierto, Romster) 16:32 <+fox> <shardy> ¡bien por la integración de Fortuna! 16:32 <+fox> <Romster> pasando al 2) :P 16:32 <+fox> <Romster> ¿qué es Fortuna? 16:32 <jrandom> je, pensé que te gustaría, shardy :) 16:32 <+fox> <Romster> he estado un poco desconectado el último mes 16:32 <+Complication> Un PRNG (algoritmo generador de números pseudoaleatorios), si recuerdo bien. 16:33 <+Complication> Supuestamente uno bueno, o eso dicen. :P 16:34 * Complication no sabe nada sobre sus entrañas, eso sí 16:34 <jrandom> shardy: me encantaría que pudieras echarle un ojo algún día 16:34 <+fox> <shardy> por supuesto 16:34 <+fox> <shardy> ¿están usando la implementación de GNU? 16:34 <jrandom> Romster/Complication: hay algunos enlaces en el correo 16:34 <jrandom> sí, shardy - http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/core/java/src/gnu/crypto/prng/Fortuna.java 16:35 <jrandom> (integrado con http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/core/java/src/net/i2p/util/FortunaRandomSource.java ) 16:36 <jrandom> sin embargo, nos apartamos de la implementación directa de gnu-crypto, ya que ya tenemos código de AES256 y SHA256 (de Cryptix y Bouncycastle, respectivamente) 16:36 <jrandom> ok, en fin, esto pinta bien, ya que llevamos probablemente un año trasteando para incorporar ese soporte 16:37 <jrandom> (la integración de Fortuna fue uno de los proyectos principales que impulsaron a smeghead a construir 'pants' ;) 16:37 <jrandom> si alguien tiene preguntas/comentarios/preocupaciones al respecto, por favor mándenlos a la lista 16:37 <jrandom> (o por email, o en el foro, claro) 16:38 <+fox> <Romster> sí, ¿dónde está smeghead? no ha estado por aquí desde hace un tiempo 16:38 <jrandom> smeghead está [redacted] haciendo [redacted] 16:39 <jrandom> ok, pasando a 3) Estado de GCJ 16:39 <jrandom> ¡i2p funciona en GCJ! [w00t!] 16:39 <+susi23> buen trabajo 16:39 <+legion> genial 16:39 <jrandom> al menos, funciona en GCJ 4.0.2 sobre Linux 2.6.12. No he probado en otras plataformas 16:40 <jrandom> sí, la gente de GCJ y GNU Classpath ha hecho maravillas 16:40 <jrandom> fue realmente fácil conseguir que compilara; aquellas clases de referencias estáticas que recuerdo ya no fueron necesarias 16:41 <+Complication> Lo cual suena bastante positivo, dado que Sun Java no es del todo abierto (en cuanto a distribución, si recuerdo bien). 16:41 <jrandom> ahora I2P se distribuye con un makefile, aunque por simplicidad, creo que probablemente seguiremos distribuyendo Java puro, al menos principalmente 16:41 <+susi23> (lo próximo es intentar ejecutarlo en J2ME ;) 16:42 <+fox> <Romster> GCJ para sustituir la JVM de Sun> 16:42 <cat-a-puss> ¿cómo es el rendimiento con GCJ? 16:42 <jrandom> sí, aunque Sun es completamente abierto, y podríamos distribuir su JVM junto con I2P, pero su licencia prohíbe distribuir su JVM como herramienta de propósito general 16:42 <jrandom> cat-a-puss: comparable 16:42 <jrandom> la mayor parte del trabajo pesado en i2p ya la hace código en ensamblador ;) 16:43 <+fox> <Romster> ¿cómo iría i2p con C#/mono otra vez con esa adición de Java a C# (olvidé su nombre) 16:43 <+fox> <Romster> recuerdo que jrandom y yo lo probamos hace tiempo 16:43 <jrandom> ni idea. pero si funciona con gcj, podría funcionar con ikvm: la cosa esa de la JVM en mono 16:44 <+Ragnarok> IKVM 16:44 <+Ragnarok> no importa 16:44 <+fox> <Romster> ah, ese es, ikvm 16:44 <+fox> <Romster> ¿muchas diferencias entre GCJ, IKVM y el de Sun? 16:45 <jrandom> nunca he usado ikvm 16:45 <+fox> <Romster> seguro que alguna vez lo hiciste con mono, ¿o era eclipse? 16:45 <+fox> * Romster se encoge de hombros 16:45 <jrandom> y i2p tal como se distribuye actualmente no admite la consola del router, aunque sí admite la operación del router, i2ptunnel y sam 16:46 <+Ragnarok> ¿qué está bloqueando la consola del router? 16:47 <+susi23> xerces, si recuerdo bien 16:47 <jrandom> cosas de xerces. La xercesImpl que enviamos con i2p tiene dependencias de sun.*, y cuando ingenuamente intenté meter el último xerces, lograr que ese, jdom, rome y el resto de jetty funcionaran con GCJ se estaba rompiendo 16:47 <jrandom> parece que la última versión de xerces tiene algunos requisitos adicionales 16:48 <jrandom> (para archivos jar que actualmente no distribuimos). sin embargo, estoy seguro de que podremos dar con ello 16:49 <+fox> <Romster> jrandom es bueno rastreando problemas :) 16:49 <jrandom> aún mejor creando problemas 16:49 <+fox> * Romster se va a por un café 16:49 <jrandom> ok, ¿algo más sobre 3) estado de GCJ? 16:49 <jrandom> ¿o pasamos a 4) i2psnark 16:50 <jrandom> consideren que ya pasamos 16:50 <jrandom> ok, i2psnark ha vuelto (yay) 16:51 <jrandom> no tengo mucho que añadir a lo que está en el mail... ¿tienes algo, Ragnarok? 16:51 <+Ragnarok> nop 16:51 <+susi23> respecto a la interfaz web 16:51 <+Ragnarok> aunque vendrían bien más pruebas, así que todos deberían probarlo :) 16:52 <+susi23> soportarlo con susibt no debería ser un problema 16:52 <jrandom> ooh, cuéntanos, susi23 :) 16:52 <jrandom> bien 16:52 <+fox> <jme___> pregunta ingenua, ¿por qué dedicar tiempo a soportar un cliente BT antiguo cuando otros (azureus) admiten un cliente completo? 16:52 <jrandom> azureus es la leche 16:52 <+susi23> el lanzamiento mayor de susibt está previsto para noviembre :) 16:53 <jrandom> je, guay, susi23 16:53 <+Complication> Para mí, Azureus parecía terriblemente complejo. 16:53 <+Ragnarok> azureus apesta 16:53 <+susi23> en mi caso, siempre necesito una solución sin interfaz (headless) 16:53 <+Ragnarok> por no andarme con rodeos 16:53 <+fox> <jme___> ok :) 16:53 <jrandom> jme___: no obstante, azureus es un poco pesado, pero es una gran solución BT de propósito general 16:53 <+Complication> (personalmente, me veo el día en que configure algo mal y dañe mi anonimato). 16:54 <+fox> <jme___> tiene sentido, solo quería saber 16:54 <+fox> <Romster> a mí Azureus nunca me funcionó bien; me pasé a BitLord, que sí funciona 16:54 <jrandom> sigo pensando ayudar a mejorar el plugin azneti2p con la gente de Azureus, pero con i2psnark tardé literalmente menos de 2 horas en estar swarmeando datos 16:54 <+legion> Sí, Azureus es demasiado grande y complicado para i2p 16:54 <+Complication> Si el objetivo es empaquetar un cliente BT junto con i2p, un cliente ligero suena mejor. 16:54 <+fox> <Romster> principio KISS 16:54 <+Ragnarok> Me gusta más el cliente oficial, pero i2psnark tiene la gran ventaja de ser lo bastante simple como para que yo pueda hackearlo 16:55 <+legion> la cosa es que i2p no necesita un cliente BitTorrent pesado 16:55 <jrandom> sí, es un código muy limpio (con ese formato raro de GNU ;) 16:55 <+Ragnarok> maldita GNU 16:55 <+Ragnarok> el peor estilo de llaves de la historia 16:55 <jrandom> je 16:55 <+fox> <Romster> je, un reformateador de código :) 16:55 <+Ragnarok> jrandom no me deja :) 16:55 <+Ragnarok> bueno, con razón 16:55 <+fox> <jme___> independencia y simplicidad son criterios con los que definitivamente estoy de acuerdo 16:56 <+fox> <Romster> ¿habrá opciones para activar el programa BT-Torrent en cada nodo de i2p? 16:56 <jrandom> sí, estaría bien si pudiéramos retroportar multitorrent, selección de piezas y capacidad web al snark principal de mjw 16:56 <+Ragnarok> cuanto más simple sea, más probable es que se mantenga 16:56 <jrandom> exaacto, Ragnarok 16:57 <+legion> sí, retroportar eso sería la leche 16:57 <+fox> <Romster> como punto off-topic, echen un vistazo a la red KAD de eMule; creo que es bastante buena. 16:57 <jrandom> Romster: ahora se incluye por defecto en la build, pero una vez lo integremos en susibt, estará en la navegación superior con el resto de clientes 16:58 <+Ragnarok> también necesitamos poder incluir un creador de .torrent. Y un tracker estaría bien. 16:58 <jrandom> sí, de hecho, snark tiene ambas cosas; solo las desactivé porque no quería mantenerlas :) 16:58 <+legion> hmm buen punto, Ragnarok 16:58 <jrandom> pero reactivarlas no sería mucho problema 16:59 <+Ragnarok> bueno, al menos el generador de torrents no debería ser tan malo 16:59 <jrandom> también hay un Tracker.java y manejo en el PeerAcceptor, pero tiré lo que no era necesario, así que probablemente convenga mirar en http://klomp.org/snark/ para eso 17:00 <jrandom> (y revisar http://dev.i2p/~jrandom/snark_diff.txt para los cambios) 17:00 <+fox> <Romster> ya que snark está de vuelta, se trabajará en ello, ¿no? :) 17:00 <+legion> de hecho, cuando se trata de un tracker, sería mejor proponer una solución distribuida 17:00 <+fox> <Romster> snark* 17:00 <jrandom> portar código es más fácil que construir un tracker distribuido nuevo, legion ;) 17:00 <+fox> <Romster> legion, ahora sí estás hablando 17:00 <+legion> cierto 17:01 <jrandom> pero no me opondría a integrar una solución de tracker distribuido, limpia, mantenida y amigable con el anonimato :) 17:01 <+fox> <Romster> ¿se podría acoplar a las eepsites? 17:01 * jrandom ve un pony volador pasar por la ventana 17:01 <+Ragnarok> el cliente BT oficial tiene un tracker distribuido basado en Kademlia, pero obviamente eso solo sirve como referencia de diseño 17:01 <+legion> un punto de partida ;) 17:02 <+fox> <Romster> en realidad ¿kademlia = la red KAD de eMule? hmm, si es el caso, KAD sería ideal para un tracker, pero el bootstrapping es un problema 17:03 <+Ragnarok> se basan en el mismo algoritmo, pero no son compatibles de ninguna manera 17:03 <+Ragnarok> compatible, vamos 17:04 <+Ragnarok> hacer algo como el KAD de eMule para i2phex sería interesante... 17:04 <+Ragnarok> en fin, ponis voladores 17:04 <jrandom> :) 17:04 <jrandom> (de acuerdo en ambos puntos) 17:04 <jrandom> ok, ¿algo más sobre 4) i2psnark? 17:05 <+Ragnarok> mientras tengamos algo para crear archivos .torrent, los trackers existentes están bien 17:05 <jrandom> buen punto: creo que hay algo de código comentado en el main de Snark 17:05 <+legion> no, creo que los trackers existentes no están bien :( 17:05 <jrandom> ¿qué les pasa, legion? 17:05 <cat-a-puss> no hay que entregar a los usuarios solo un archivo torrent tampoco 17:05 <jrandom> hmm ¿cat-a-puss? ah, quieres decir que necesitamos una interfaz web para swarmeo transparente? 17:06 <+legion> los sitios se saturan de tráfico 17:06 <jrandom> ah, ese es un problema de i2p; con suerte la 0.6.1.4 lo mejorará 17:06 <jrandom> postman me decía que estaba recibiendo montones de visitas en tracker.postman.i2p 17:06 <jrandom> olvido las cifras de memoria 17:06 <cat-a-puss> Si gestionamos tanto el código de swarming como el código para obtener el torrent en primer lugar, mejor hacerlo transparente para el usuario 17:07 <jrandom> orion.i2p/bt/ no se usa mucho, eso sí 17:07 <jrandom> (y tracker-fr parece animado) 17:07 <+susi23> con susibt espero incluir el feed RSS de los trackers, para que ya no tengas que ir a la web del tracker, sino que se descarguen los torrents automáticamente :) 17:07 <cat-a-puss> también evita confundir un torrent de i2p con uno no anónimo 17:07 <+fox> <jme___> el tracker HTTP para BT no escala debido a un protocolo mal diseñado 17:07 <+fox> <Romster> router watchdog: el router se colgó fuerte, reinicio wtf 17:07 <+legion> exacto, que es mi punto: algunos trackers están inundados mientras otros están ociosos 17:07 <jrandom> ah, sí, me encantaría integrar hooks de syndie en susibt :) 17:07 <+fox> <jme___> se puede arreglar fácilmente pero rompe la compatibilidad con el protocolo BT oficial 17:08 <+fox> <jme___> es el camino que sigue lo del tracker con DHT 17:08 <jrandom> (y al revés, para que la gente pueda sindicar fácilmente archivos .torrent, etc.) 17:08 <+Complication> Romster: me pasa eso, pero la máquina en la que me sucede va justa (300 MHz) 17:08 <+fox> <Romster> el tracker distribuido es la solución a los trackers saturados 17:08 <jrandom> legion: eso se puede remediar fácilmente si la gente usa trackers diferentes :) 17:08 <+fox> <Romster> DHT de Azureus 17:08 <jrandom> el código es caro; usar URL diferentes es barato 17:08 <+legion> sí, pero no parece que lo estén haciendo, ¿no? 17:09 <jrandom> pero sí, un tracker distribuido estaría genial. No está en mi roadmap, pero si alguien lo pone en marcha, sería la caña. 17:09 <+Complication> A su debido tiempo... seguro que alguien puede irse a distribuido también. 17:09 <+legion> En lugar de publicar los torrents en sitios de trackers, podrían publicar un bith y los detalles en su eepsite. 17:10 <jrandom> bith == hash? 17:10 <+legion> sí, significa bittorrent hash; no es término mío 17:10 <+Complication> Al principio, eso sí... un cliente sencillo y sólido, en Java, integrado con el router... puede resolver muchos problemas. (Quizá incluso obtener actualizaciones firmadas sin sobrecargar dev.i2p). 17:11 <+legion> sí, eso estaría genial 17:11 <jrandom> cierto, Complication 17:11 <+fox> <Romster> sí, actualizaciones por torrent 17:11 <+fox> <Romster> ok, siguiente punto de la lista :) 17:12 <jrandom> ok, 5) más sobre el bootstrapping (proceso inicial de incorporación) 17:12 <+legion> sí, sigamos 17:12 <jrandom> últimamente hay muchas cosas interesantes en la lista, y no voy a resumirlo todo aquí :) 17:12 <+fox> <Romster> ¿bootstrapping de la base de datos del router de i2p? 17:12 <jrandom> ¿alguien tiene preguntas/comentarios/preocupaciones que quiera discutir sobre el hilo? 17:12 <jrandom> Romster: mira la lista y/o el email 17:12 <+fox> * Romster necesita leer esa lista 17:13 <jrandom> sí, hay cosas buenas ahí :) 17:13 <+fox> <Romster> he estado bastante ocupado últimamente 17:13 <+Complication> 26 mensajes por leer, aún no puedo comentar 17:13 <jrandom> aún sin resultado final, pero estamos mirando un nuevo modo de construir tunnels para la 0.6.2 17:14 <+fox> <Romster> ¿una forma nueva? ¿hay un defecto en el método actual? 17:14 <+fox> <Romster> flaw* 17:14 <jrandom> El análisis de Michael muestra que el ataque no es realmente un problema ahora, ya que hay ataques más fáciles sobre las alternativas 17:14 <jrandom> lee la lista ;) 17:14 <+fox> <Romster> arg, después 17:14 <+fox> <Romster> esto es ahora :) 17:15 <+fox> <Romster> normalmente estoy dormido a esta hora. 17:15 <+fox> <Romster> así que rara vez puedo estar en una reunión 17:16 <cat-a-puss> ¿puedes publicar tus ideas para una forma nueva / existentes / rechazadas en un email a la lista para poder comparar? 17:16 <+fox> <Romster> así que tiene que ver con métodos de ataque y creación de tunnels, supongo, sin haber leído aún la lista 17:16 <cat-a-puss> (eso es para Jrandom) 17:16 <jrandom> no estoy seguro de que hayamos concretado un resultado final todavía 17:16 <+fox> <Romster> sería una idea, cat-a-puss 17:17 <+Complication> Romster: sí, era más o menos sobre darle al endpoint de un exploratory tunnel menos información como posible atacante 17:17 <jrandom> pero http://dev.i2p.net/pipermail/i2p/2005-October/001073.html es lo último de lo que veo que sale de tu sugerencia 17:17 <jrandom> bueno, no influencia (i2p es una mixnet de rutas libres), sino menos información 17:18 <+Complication> Sí, ese sería un término más correcto 17:18 <jrandom> (la URL enlazada arriba está llena de teorías al aire; aún no hay cripto sólida definida) 17:18 <+fox> <Romster> menos = mejor para más robustez contra ataques, entiendo por dónde vas 17:18 <jrandom> ((pero creo que todo es factible con técnicas existentes) 17:19 <jrandom> Romster: aquí hay una gráfica del ataque de Michael contra el algoritmo actual, con el eje X indicando qué % de la red está comprometido: http://dev.i2p.net/~jrandom/fraction-of-attackers.webp 17:20 <jrandom> (la construcción telescópica simple estaría fuera de la gráfica antes de llegar a x=200) 17:20 <jrandom> ((así que lo que tenemos ahora es literalmente órdenes de magnitud mejor)) 17:20 <jrandom> pero podemos mejorarlo aún más 17:21 <jrandom> aunque también está la alternativa de garlic routing 17:21 <jrandom> en fin, sí, hay más cosas que concretar; estén atentos a la lista :) 17:21 <+fox> <Romster> ok, le daré una buena leída a esa lista más tarde 17:22 <+fox> <Romster> y ver si se me ocurre algo que añadir 17:22 <jrandom> guay 17:22 <cat-a-puss> ¿el método telescópico «nuevo» sería lo bastante rápido como para hacer construcción bajo demanda? 17:22 <jrandom> no estoy seguro de que queramos eso 17:22 <jrandom> es el tema de O(1) vs O(N) 17:23 <jrandom> la técnica nueva permitiría crear tunnels sin usar los exploratory tunnels, dejando los exploratory tunnels para la operación de la netDb 17:23 <jrandom> (y para la creación de exploratory tunnels :) 17:24 <+fox> <Romster> hrmm, ¿valdría la pena fastidiar a los atacantes dándoles montones de falsos positivos, enmascarando así la fuente real? 17:24 <+legion> suena bien :) 17:24 <+legion> creo que algo de ese «engaño» estaría bien 17:24 <cat-a-puss> jrandom: claro, preguntaba si hacerlo aceleraría lo suficiente como para que a veces los últimos hops no sepan que son el último hop, como se disfrazó en la lista. 17:25 <+fox> <Romster> ¿exploratory tunnels para recolectar referencias de routers en la netDb? 17:25 <jrandom> romster: nosotros somos los hackers ;) pero sí, si los falsos positivos superaran a los verdaderos, se requeriría un número sustancial de ataques para obtener datos estadísticamente significativos 17:26 <jrandom> hmm, vale, cat-a-puss, pero no sé cómo aceleraría eso; nos movería de una topología de tunnels O(1) a O(N) 17:26 <jrandom> o ¿a qué te refieres con acelerar las cosas? 17:26 <+fox> <Romster> y si llegara al punto de ser detectado, ¿podría entonces «apagarse» y quedarse en silencio un tiempo? 17:26 <jrandom> usar la técnica nueva reduciría sin duda las creaciones de tunnels fallidas 17:26 <+fox> <Romster> o cambiar su clave disimuladamente y continuar o algo así, je 17:26 <jrandom> romster: probablemente valga la pena escarbar en los correos para revisar el ataque ;) 17:27 <+fox> <Romster> sí, después de dormir 17:27 <+Complication> Romster: por lo que sé, es mayormente un ataque pasivo, así que el objetivo no puede detectar que está ocurriendo 17:27 <+fox> <Romster> y arreglar la PC de un amigo que tengo aquí 17:27 <+fox> <Romster> ah, entiendo, Complication. 17:27 <cat-a-puss> jrandom: no hablo de lo de O(n). Me refiero a esperar a construir un tunnel de cliente hasta que lo necesitemos para algunas apps, en lugar de tenerlos ahí todo el tiempo. 17:28 <+Complication> (pero puedo estar equivocado, y esos últimos 26 mensajes podrían tener componentes activos) 17:28 <+fox> <Romster> ¿un ataque pasivo a largo plazo eventualmente encontraría el objetivo? 17:28 <+fox> <Romster> comentaré después de leer la lista 17:28 <jrandom> ah, cat-a-puss, sin duda mejoraremos el pooling de tunnels para la 0.6.2. Actualmente solo construimos el tunnel cuando lo necesitamos (dándonos un poco de tiempo por si la creación falla) 17:28 <+Complication> Romster: bueno, mantener el ataque más allá de la vida del tunnel requeriría recursos y paciencia 17:28 <+fox> <Romster> y entenderlo mejor 17:29 <+Complication> Pero el tiempo influye en toda probabilidad de éxito. Cuanto más tiempo pruebas, más oportunidades tienes. 17:29 <+fox> <Romster> ah, esa es la idea: que la vida del tunnel sea demasiado corta para que un ataque valga la pena. 17:29 <jrandom> cada pool tiene un número definido de tunnels de respaldo, y por defecto construimos reemplazos entre 60 y 120 segundos antes de que caduque uno viejo 17:29 <+fox> <Romster> ¿no hay interacción entre cada tunnel para recopilar estadísticas? 17:30 <jrandom> correcto, Complication: cada muestra ocurre solo 'm' veces cada (c/n) tunnels 17:30 <+fox> <Romster> mientras uno está a punto de expirar y se está construyendo otro 17:31 <jrandom> romster: los nuevos tunnels no se hablan entre sí, no; pero ese no es el ataque que Michael ha estado describiendo 17:31 <jrandom> hay incontables ataques ahí fuera, la mayoría de los cuales ya hemos tratado, pero cada vez que alguien plantea uno que pueda afectar a la operación de I2P, queremos analizarlo más a fondo 17:31 <+fox> <Romster> tengo que leer la lista; ok, lo dejo ahí por ahora, ¿alguien más tiene algo que decir? 17:32 <jrandom> ok, si no hay nada más, pasemos a 6) investigaciones sobre virus 17:32 <+fox> <Romster> en realidad, una estadística que veo que podría recopilarse es: sin 0 hop significaría que el siguiente hop no es el punto final, así que se podría descartar, pero con millones de nodos esa técnica de análisis sería inútil 17:33 <jrandom> no tengo nada que añadir más allá de lo que se ha discutido en el foro 17:33 <jrandom> cierto, Romster; hay ataques de predecesor sobre la longitud del tunnel, que es una de las cosas principales que abordamos en la 0.6.2 17:33 <+fox> <Romster> virus, ¿qué virus? si es Linux será inexistente, pero en Windows, hmmm 17:34 <+Complication> Bueno, aunque no pude construir un binario equivalente (quién sabe por qué), la diferencia final fue lo bastante pequeña... como para que, con suerte, sea útil a quien le interese leer código ensamblador. 17:34 <jrandom> Romster: por favor, las notas de estado semanales deberían explicar estos puntos de la agenda, y la reunión es para discutir cosas /más allá/ de lo que está en las notas ;) 17:35 <+Complication> Seguro que no pude encontrar nada obvio ahí, pero tampoco pude explicar todas las diferencias. 17:35 <@cervantes> rtfml y rtff 17:35 <+fox> <Romster> sí, no he estado al día desde hace un buen rato, perdón por eso, jrandom 17:35 <@cervantes> ;-) 17:35 <jrandom> sí, el hecho de que tanto un archivo .bat conocido como seguro como el antiguo activaran el mismo código de detección es significativo 17:35 <+Complication> Sí, eso reduce las dudas. 17:36 <+Complication> Supongo que QBFC podría tener diferencias no documentadas dentro del mismo número de versión (¿builds diferentes?) 17:37 * jrandom no tiene idea, pero posiblemente sea alguna interacción con el SO o lo que sea. No sé; has puesto suficiente análisis para que la gente tome su propia decisión informada 17:37 <+Complication> Creo que es mejor así. 17:37 <+Complication> El desensamblado está realmente fuera de mi terreno habitual. 17:37 <jrandom> legion: ¿quieres mencionar algo sobre esto, o la gente debería ir al foro si quiere más info? 17:38 <@cervantes> ¿puedo reiterar lo que otros han dicho en el foro y agradecer a Complication el tiempo y los meticulosos intentos que ha invertido en analizar este asunto? 17:38 <jrandom> sí, se agradece mucho 17:38 <+legion> No tengo nada que añadir; siento que ya he dicho demasiado al respecto 17:39 <jrandom> 'k, entendido. ok, ¿alguien más quiere mencionar algo sobre esto, o pasamos a 7) ??? 17:39 <jrandom> [consideren que ya pasamos] 17:40 <+fox> * Romster secundo eso :) 17:40 <+legion> para 7)??? ¿qué tal si dedicamos un momento a hablar de i2phex 17:40 <jrandom> genial, buena idea 17:40 <+fox> <Romster> ya que lo estoy usando ahora mismo :) 17:40 <@cervantes> no no, primero abrazo grupal 17:40 <jrandom> redzara mencionó que iba a estar en la reunión, pero el progreso de la fusión va lento 17:41 <+legion> susi23 preguntó por una versión headless 17:41 <jrandom> ah, genial, vi tu post sobre eso 17:41 <+fox> <Romster> añado que la lista de favoritos debería ser más ancha para soportar las claves de i2p más largas 17:42 <+susi23> (no es imprescindible, solo tenía curiosidad) 17:42 <jrandom> bueno, nadie puede recordar claves en base64, así que no estoy seguro de que te estés perdiendo mucho, Romster ;) 17:42 <jrandom> (y los primeros bytes deberían bastar para identificarlas de forma única) 17:42 <+fox> <Romster> iniciar i2phex con un servidor es el mayor problema que veo hasta ahora 17:42 <+legion> De hecho me gustaría que en el cliente solo se mostraran como los primeros 12 caracteres de las claves 17:42 <+fox> <Romster> je, supongo 17:43 * Complication por desgracia está muy ocupado y no puede hacer nada de xml-rpc 17:43 <jrandom> suena razonable, legion 17:43 <+fox> <Romster> ¿y mostrar tantos caracteres como hagan única la clave? 17:43 <jnymo_> Estoy teniendo buenos resultados con i2phex 17:44 <jrandom> genial, jnymo_, yo también he oído cosas buenas 17:44 <+fox> <Romster> así que si 2 claves empiezan con abc, será abcx 17:44 <jnymo_> 12 caracteres idénticos no es probable, romster 17:44 <+fox> <Romster> cierto 17:44 <+Complication> Además, más simple = más rápido 17:44 <+fox> <Romster> (no es que haya mucho que ganar en velocidad por mostrar cosas) 17:45 <+Complication> (no es que haya mucho que ganar en velocidad por mostrar cosas) 17:45 <+legion> Bueno, quizá podría haber una ventana nueva de propiedades del host, indicando la clave completa y cierta información como cuánto comparte y lo que sea 17:45 <+susi23> (la netDb funciona de maravilla con solo 4 caracteres para IDs de router) 17:45 <+fox> <Romster> o la base de datos usando keyname=base64 y mostrando solo el keyname 17:45 <jrandom> hmm, ¿pensé que ya había una vista de info del peer, legion? 17:46 <jrandom> legion: cosas así sería bueno añadirlas a la línea principal de phex, probablemente? 17:46 <+legion> hmm podría ser... 17:46 <jrandom> (así Gregor puede mantenerlo ;) 17:46 <+Complication> Bueno, hay una función «Browse host», pero puede que no sea exactamente lo mismo. (Si funciona). 17:46 <jrandom> Complication: sí funciona 17:46 <jrandom> (funciona, quiero decir) 17:47 <+Complication> Parece que básicamente coloca la destkey del host en el cuadro de búsqueda 17:47 <+Complication> ...y ejecuta una búsqueda. 17:48 <jnymo_> esto puede ser un tema de la línea principal de i2phex, pero no vi un ETA para las descargas de i2phex 17:48 <+Complication> Hmm... o en realidad, no ejecuta una búsqueda. 17:48 <+Complication> El mío parece esperar hasta que la inicio manualmente. 17:48 <+fox> <Romster> ¿para qué es la casilla de «i2phex cercano en ejecución»? 17:49 <+legion> Veo que hay mucho margen de mejora. ;) 17:49 <jrandom> sí :) 17:50 <jrandom> hay mucho por hacer, y el foro es un buen lugar para publicar ideas/sugerencias/preguntas(/parches :) 17:50 <+fox> <Romster> a pesar de su nombre obvio 17:50 <jrandom> ok, ¿alguien tiene algo más para la reunión? 17:50 <+fox> <Romster> buen punto 17:50 <+fox> <Romster> no se me ocurre nada más 17:51 <+fox> <Romster> ¿pero hay alguien trabajando en un almacén de datos distribuido? 17:51 * cervantes mira su reloj 17:51 <+fox> <Romster> activamente, digo 17:51 <jrandom> Romster: más allá de syndie, no 17:51 <jrandom> (que yo sepa, al menos) 17:52 <+legion> pues me preguntaba acerca de integrar un gestor de descargas HTTP en i2p; facilitaría descargar contenido grande desde eepsites. 17:52 <+fox> <Romster> q e iphex y uno o dos más, pero no he visto nada mantenido desde hace tiempo 17:52 <@cervantes> ¿cuál es el estado de feedspace...? No he oído nada desde hace un tiempo 17:52 <jrandom> legion: eso estaría bien; creo que también hay un post sobre eso en el foro 17:53 <+fox> <Romster> ah, feedspace, otro más 17:53 <jnymo_> si esto ya se mencionó en la reunión, nm... pero, ¿hay novedades sobre la colaboración i2p-freenet? 17:53 <jrandom> cervantes: lo último que supe es que frosk estaba algo ocupado, pero si frosk anda por aquí, quizá pueda contarnos más :) 17:53 <+legion> Personalmente me gustaría ver una colaboración i2p-entropy. 17:54 <+fox> <Romster> tengo ideas para un datastore, pero sería una ampliación de métodos existentes que ya se usan actualmente 17:54 <+legion> Dado que q, feedspace y demás no parecen avanzar muy rápido ahora 17:54 <jrandom> jnymo_: les pasé a los de Freenet algo de código para ejecutar sobre nuestro transporte SSU; toad se ha sumado a algunas discusiones, pero Freenet no estará en posición de que lo ejecutemos como data store encima de i2p por un tiempo (probablemente después de que salga su versión 0.7) 17:54 <+fox> <Romster> quiero iniciar un proyecto pero no repetir lo que otros ya han hecho 17:54 <+legion> me pregunto si sería posible portar entropy para que funcione sobre i2p... 17:54 <jrandom> legion: entropy estaría bien, pero la integración es algo difícil. por supuesto, la gente podría ejecutar cosas como fproxy.i2p para entropy 17:55 * jrandom no conoce para nada el código de transporte de entropy 17:55 <+fox> <Romster> he puesto en pausa mi cliente de IRC; ya hay muchos en progreso. Todo lo que i2p necesita ahora es un datastore y superará a Freenet con facilidad :) 17:55 <jrandom> (pero quizá sería una buena forma de que alguien hackee el SDK de GCJ :) 17:56 <jrandom> Romster: ayudar en otros esfuerzos es mucho más gratificante que empezar proyectos completamente nuevos, ya que haces mucho más con menos esfuerzo :) 17:56 <jnymo_> ah... felicitaciones por el port a GCJ 17:56 <+fox> <Romster> entropy está en C o C++, iirc 17:57 <jrandom> correcto, Romster, por eso podrían usar el SDK de I2P y la librería de streaming, construidos con GCJ en bibliotecas nativas 17:57 <+fox> <Romster> cierto, jrandom, pero ¿quién? :) 17:57 <jrandom> yo no 17:57 <+legion> ah, y sobre otro tema, solo mencionar que hoy publiqué una nueva versión de mi actualización de readme.html para la consola del router de i2p. 17:57 <jrandom> (la única manera de lograr algo que te importa es que lo hagas tú :) 17:57 <jrandom> guay 17:57 * dust le gustaría ver algún tipo de sindicación «squid» para descargar carga de las eepsites 17:58 <jrandom> dust: sí, totalmente; si pudiéramos poner a sucker en esa posición, sería ideal 17:58 <jrandom> p. ej., me encantaría obtener la info más reciente de orion en syndie, local 17:58 <+fox> <Romster> construyan un proxy para que squid lo use :) 17:59 <+legion> Lo había estado posponiendo con la esperanza de que ciertas mejoras al python eepsitechecker estuvieran hechas ya. 17:59 <dust> ah, syndie 17:59 <jrandom> (para eso es en realidad syndie: sindicación para reducir la carga) 17:59 <dust> la respuesta 17:59 <jrandom> ¿hay un comprobador de eepsites en python? 17:59 <+fox> <Romster> es la primera vez que lo oigo 17:59 <+legion> sí, es lo que uso ;) 18:00 <jrandom> genial, legion 18:00 <+legion> ¿de verdad? Ha estado por ahí un tiempo 18:00 <+fox> <Romster> bien, me gustaría mirarlo :) 18:00 <@cervantes> creo que alguien portó el script de baffled... no recuerdo quién/cuándo 18:00 <+fox> <Romster> estoy aprendiendo python 18:00 <jrandom> ah, ok, cervantes 18:00 <+fox> <Romster> a la dura, con ejemplos y el manual :) 18:00 <jrandom> sí, soy vago; solo uso polecat.i2p/i2psurvey/ y orion.i2p/ :) 18:01 <jrandom> (no necesito hacer spider) 18:01 <+legion> si alguien quiere trabajar conmigo en ello, me gustaría de verdad arreglar el código y hacerlo funcionar con python 2.3 o 2.4 18:01 <+fox> <Romster> tengo 2.4 instalado aquí 18:01 <+Ragnarok> Puede que le eche un vistazo. ¿Tienes enlace? 18:01 <+fox> <Romster> en realidad creo que es 2.4.1 18:02 <+legion> ahora mismo no tiene compatibilidad con py2exe y la mitad funciona con cada versión, lo que significa que quien lo ejecute necesita tener ambas instaladas. 18:02 * jnymo_ le encantaría ver un híbrido orion.i2p/I2PDirectory... info, categorías, estadísticas... mantequilla 18:02 <+legion> Lo archivaré después de la reunión y pondré un enlace en los foros 18:03 <+Ragnarok> ok 18:03 <jrandom> legion: hmm, ¿ves a mucha gente necesitando ejecutar eso? Quiero decir, solo unas pocas personas necesitan hacer spider 18:03 <+fox> <Romster> ambas, eck, quizá sea demasiado para que yo lo traduzca a la más nueva; no sé hasta que vea el código 18:03 <jrandom> (no es que haya nada malo en ponérselo fácil a esas pocas personas :) 18:04 <+fox> <Romster> ¿podría diseccionarse y usarse para hacer otras cosas también? 18:04 <+legion> El caso es que veo que podría haber usos para todos los que ejecutan i2p. 18:04 <+fox> <Romster> podría* 18:04 <jrandom> hmm, no estoy seguro, ¿podrías explicar cómo? 18:04 <jrandom> Quiero decir, no quiero que todos hagan básicamente un DDoS a cada eepsite 18:05 <+legion> Uno sería una página de marcadores dinámica, generada automáticamente cada 12-24 horas o así. 18:05 <jrandom> ah, eso es trivial en syndie (actualmente una de las características principales - 'new blogs') 18:05 <jrandom> ((pero claro, syndie no tiene aún una gran UI para eso)) 18:06 <+fox> <Romster> en realidad solo haría falta que unos pocos hiciesen spider y lo metiesen en una base de datos tipo torrent/DHT y sincronizar eso entre nodos 18:06 <jrandom> cierto, Romster (aunque esa base de datos tipo torrent/DHT para sincronizar, o «sindicar», podría ser syndie ;) 18:06 <+fox> <Romster> incluso podría ser una forma oculta de aprender más nodos y servicios de i2p 18:07 <+fox> <Romster> sí, o syndie 18:07 <jrandom> ok, ¿alguien más tiene algo para la reunión? el curry se está enfriando ;) 18:08 <+fox> <Romster> si syndie va a ser tan bueno, se podrían almacenar páginas estáticas en caché y lo mismo con imágenes 18:08 <+fox> <reliver> bon appetit, jrandom :-) 18:08 <jrandom> exacto, romster, eso ya se puede hacer 18:09 <jrandom> ok, si no hay nada más... 18:09 * jrandom va terminando 18:09 * jrandom cierra la reunión con un *baf*