Resumen rápido
Presentes: co, jrand0m, LeerokLacerta, mihi, mrflibble, mrsc, nop, shardy, thecrypto, w0rmus
Registro de la reunión
[22:53] 0) bienvenidos [22:54] 1) apps: [22:54] 1.1) IM [22:54] 1.2) NS [22:54] 2) estado de dev: [22:54] 2.1) subsistemas [22:54] 2.2) persistencia de claves de cifrado [22:54] 2.3) por hacer [22:54] 3) cosas de la spec [22:54] 3.1) mods [22:54] 4) administrivia: [22:54] 4.1) anon cvs [22:54] 5) ? [22:55] ok, 0) bienvenidos [22:55] bienvenidos a la reunión 58 [22:55] eso es todo [22:55] sí, señor, a menos que alguien más tenga cosas que añadir? [22:55] * nop se da cuenta de que jrand0m es orientado a objetos con su numeración :) [22:56] 3.1.2.2.4.5.8() ;) [22:56] oye, podrían ser structs ;) [22:56] jaja [22:56] eso es definitivamente cierto [22:56] ok, 1.1) IM. thecrypto? [22:56] aunque [22:56] 2 tiene herencia [22:57] ;) [22:57] je [22:57] no me hagas caso [22:57] ok [22:57] perdón [22:57] continúa [22:57] *** mihi_ (~none@anon.iip) se ha unido al canal #iip-dev [22:57] bien, ahora mismo estoy subiendo algunas specs básicas para IM [22:58] (Link: http://www.thecrypto.org/i2pim.sxw)http://www.thecrypto.org/i2pim.sxw para oowriter [22:58] y estoy trabajando en subir el pdf [22:59] si quieres puedo ponerlo en el sitio de i2p [22:59] dame un segundo [22:59] seguro [22:59] *** mrflibble (mrflibble@anon.iip) se ha unido al canal #iip-dev [22:59] ¿quieres poner eso en i2p/apps/IM/doc/ ? [22:59] *** mihi_ ahora se llama mihi_backup [23:00] puedo [23:00] sí [23:00] Me refería en cvs :) [23:00] yo también puedo hacerlo [23:00] (pero en la web también está bien) [23:00] oh [23:00] jaja [23:00] (Link: http://www.thecrypto.org/i2pim.pdf)http://www.thecrypto.org/i2pim.pdf [23:01] "the file is damaged and could not be repaired" error de AR [23:01] inténtalo de nuevo [23:01] * jrand0m lo cargó bien [23:01] MrEcho: ¿El archivo PDF? [23:01] (el sxw) [23:01] solo estaba parcialmente subido en ese momento [23:01] ahora funciona [23:01] jeje [23:02] básicamente solo puse lo de presencia, mensajes en línea/fuera de línea y un mensaje de mensaje [23:02] me pité sin vergüenza algunas secciones del documento I2NP [23:02] :) [23:02] je, pensé que algo me resultaba familiar :) [23:02] también estoy trabajando en subir la UI que [23:02] he estado haciendo [23:03] jrand0m: ¿necesito crear los dirs apps/IM/doc [23:03] sí, y hacer cvs add de cada uno individualmente [23:03] -kb? [23:03] sí [23:03] thecrypto: Creo que apps/ ya está ahí. [23:04] ¿qué es una presencia? [23:05] déjame ejecutar update [23:05] pero está entrando [23:05] *** Desconexión: shardy (Ping timeout) [23:05] solo digo que destripen las specs [23:05] y la UI también estará ahí pronto [23:05] y si hay algo que necesite aclaración entonces anonymail, e-mail, lo que sea, a mí y lo arreglo [23:05] ¿me perdí la reunión? [23:05] *** shardy (~shardy@anon.iip) se ha unido al canal #iip-dev [23:05] thecrypto: Podrías anunciarlo también en la lista de correo, con un enlace a los documentos. [23:05] ¿pensé que lo puse ahí? [23:05] nope, aún en el primer punto, mrflibble [23:05] mrflibble: La reunión está en curso. [23:05] oh perdón, no podía ver "logger" [23:06] thecrypto> dices que es un destino, pero ¿es ese el destino al que enviar mensajes? ¿cómo funcionan los mensajes fuera de línea? [23:06] no hay mids aquí, así que no hay logger ;) [23:06] k [23:06] * mrflibble vuelve a lurkear [23:06] oh espera, estos son solo avisos de presencia, perdón [23:06] ¿cómo puede uno suscribirse a una presencia? [23:06] jrand0m: no hay mensajes fuera de línea [23:07] básicamente [23:07] la presencia solo envuelve un destino y un nombre juntos [23:07] para facilitar las cosas [23:08] así que si queremos pasar a NS podemos hacerlo, ¿y volvemos a esto luego? [23:09] 'k, genial [23:09] y aún puedes mandarme preguntas [23:09] de hecho, una pregunta rápida [23:09] dispara [23:09] entonces, ¿el IM es estrictamente solo texto? [23:10] con este básico sí, pero añadiré soporte de archivos [23:10] coo' [23:10] solo quiero que se resuelvan los inicios del sistema y construir sobre ello [23:10] (iterativo e incremental)++ [23:11] ok, genial. Lo revisaré más a fondo y otros también deberían... por ahora, pasamos a 1.2) NS. co? [23:11] La versión 1.1 (final) de la especificación del servicio de nombres fue publicada hoy más temprano. [23:12] (y hubo mucho regocijo) [23:12] Básicamente, terminé las secciones sobre las estructuras de datos y los mensajes de red que el programa necesita. [23:12] Publicaré la API del cliente el jueves. [23:12] Y empezaré a implementar la aplicación NS. [23:12] genial [23:13] Una idea que ha cambiado es lo que hace la CA cuando las entidades se registran con ella. [23:13] co: ¿cómo lo vas a implementar? [23:13] co: ¿el servidor de nombres o el cliente? [23:14] thecrypto: Bueno, primero implementaré las estructuras de datos necesarias. [23:14] Luego, el cliente, después los componentes de servidor y CA. [23:14] ok [23:15] Como decía, ahora me gustaría que la CA emita un certificado a las entidades recién registradas. [23:15] Presentarán este certificado a los servidores de nombres cuando modifiquen sus registros. [23:15] No he especificado qué contiene el certificado en esta versión; eso irá en la próxima versión de la especificación. [23:16] ¿A alguien le parece una mala idea? [23:16] hmm. ¿no sería más simple/seguro que el cliente use una clave pública/privada? [23:16] o sea, durante el registro, proporcionar una clave pública para actualizaciones y firmar el registro, y cuando quieras actualizar de nuevo, firmar una actualización [23:16] (para que la CA nunca obtenga la clave privada) [23:17] Nota: todo lo de I2PIM ya está comprometido en el repositorio cvs [23:17] genial [23:17] Puede ser más simple hacer justamente eso. Voy a repensar este asunto. Gracias por el comentario. [23:17] Eso es todo lo que tengo para discutir sobre el servicio de nombres por ahora, si no tienen otras preguntas. [23:18] va bien, aún no he leído la 1.1 pero enviaré un e-mail si encuentro algo [23:19] OK. ¿Siguiente tema? [23:19] ok, 2.1) estado de dev para subsistemas. [23:19] *** w0rmus (o0o@anon.iip) se ha unido al canal #iip-dev [23:20] el subsistema de transporte está lo suficientemente bien como para avanzar. el subsistema de gestión de pares está esbozado con algoritmos tontos pero funcional. los subsistemas de net db, gestión de túneles y gestión de estadísticas aún pendientes. el subsistema de cliente será trivial (solo reutilizar el router local-only del SDK) [23:21] ¿Qué quieres decir con algoritmos tontos? [23:21] ¿no rápidos? [23:21] eh, el subsistema de gestión de pares no está llevando registro del rendimiento de los pares, solo devuelve pares aleatorios. [23:22] el algoritmo se actualizará y ajustará conforme avancemos para proporcionar una selección de pares más adecuada [23:22] la tarea actual que tengo es construir y manejar garlic messages (mensajes "garlic"), lo cual es un PITA. [23:23] pero manejable, solo molesto [23:23] eso de hecho nos lleva a 2.2) persistencia de claves de cifrado. [23:24] los garlic messages usan cifrado ElG+AES para envolver las capas de los gajos [23:24] y las claves privadas se usan en otros lugares (transporte, gestión de clientes) [23:25] *** Desconexión: thecrypto (Ping timeout) [23:25] mantener siempre en memoria las claves privadas y de sesión y nunca en disco es ideal, pero es una faena cuando el router se cae (ya sea intencionalmente o por fallo) [23:26] ¿alguien tiene alguna opinión sobre si deberíamos 1) nunca escribir las claves a disco y arriesgar perder mensajes innecesariamente en exceso (ya que no serán descifrables) 2) cifrarlas antes de escribirlas a disco o 3) simplemente escribirlas en disco en claro? [23:26] Opción 2. [23:27] jrand0m opción 2, o haz lo que dijimos antes [23:27] debemos confiar en localhost [23:27] *** Desconexión: cohesion (class) [23:27] asumimos que localhost no está comprometido [23:27] lo raro de la opción 2 es que o el usuario tendrá que introducir una frase de paso para iniciar el router, o la clave de sesión será conocible [23:27] buen punto, nop. [23:28] de nuevo, somos un transporte, no podemos preocuparnos tanto por eso, eso se puede modificar del lado del cliente, o podríamos darles opciones [23:28] según el nivel de paranoia [23:28] medida de seguridad vs. conveniencia [23:29] Entonces propongo tener 3 por defecto, y darle al usuario la opción de usar 2. [23:29] exactamente [23:29] correcto. ok, lo bueno es que la gente puede (¡y debería!) tomar el código del router y modificarlo para ese compromiso: un "tinfoil I2P router" y un "jane sixpack I2P router" [23:29] ok, genial, entonces por ahora me quedaré con la simple 3) [23:30] ok 2.3) por hacer [23:30] * a co le gustaría volver al tema NS al final de la reunión. [23:30] * nop necesita terminar de leer el correo de NS [23:30] 'k, ahora eres el punto #5 [23:30] Puedo esperar hasta el final. [23:31] mihi preparó algunas pruebas para señalar algunos bugs en la impl del SDK. algunos ya arreglados, otros no. arreglarlos está en la lista de pendientes :) [23:32] además, ha habido como una docena de cambios en varias specs. cuando tenga tiempo actualizaré los docs y los publicaré, aunque quizá ponga una página de errata en el wiki mientras tanto [23:33] word [23:34] otros pendientes... um, arreglé lo de "Wrong Size generating key" esta mañana más unos cuantos bugs aleatorios [23:34] ok, eso es todo por estado de dev. 3) cosas de la spec [23:35] 3.1) ver por hacer respecto a mods. han sido mayormente cambios tipográficos, me encontré con uno un poco más grande hoy al implementar los garlics. sigue sin problema, solo requiere mover algunas estructuras de datos y hacer algunos malabares con el cifrado. lo pondré en la errata. [23:35] 3.2) [Ya sé, este no estaba en la agenda, pero aquí va igual] preguntas de la spec [23:35] (brb, sigo al acecho si me necesitan) [23:35] ¿alguien tiene preguntas sobre alguna de las specs? [23:35] bien, shardy [23:36] jrand0m: Por favor recuérdanos de nuevo qué spec está en qué documento. [23:37] (Link: http://wiki.invisiblenet.net/iip-wiki?I2PProtocolSpecs)http://wiki.invisiblenet.net/iip-wiki?I2PProtocolSpecs las tiene mapeadas [23:37] Le echaré un vistazo. [23:38] (viendo eso me recuerda que necesito documentar el transporte UDP fiable y seguro. otra tarea más...) [23:39] ha habido algunas preguntas de varias personas respecto a qué specs mirar: básicamente, a menos que quieras saber cómo funcionan los routers (o quieras ayudar a implementarlos), no necesitarás leer la spec de I2NP. I2CP y la sección de I2CP de las estructuras de datos es suficiente [23:40] jrand0m [23:40] ¿sí, señor? [23:41] ¿te refieres a UDP real como en paquetes UDP [23:41] o UDP como un protocolo UDP general [23:41] sí, UDP como en paquetes UDP [23:41] para I2P [23:41] *** thecrypt1 (~thecrypto@anon.iip) se ha unido al canal #iip-dev [23:41] *** thecrypt1 ahora se llama thecrypto [23:41] i2p/code/router/java/src/net/invisiblenet/i2p/router/transport/udp para la implementación [23:42] de vuelta [23:42] wb [23:42] ¿alguien quiere enviarme lo que pasó mientras no estaba? [23:43] la impl de UDP es bastante simple: hace un intercambio DH y los mensajes se dividen en paquetes de 1K y se cifran con AES256 con la clave generada [23:43] se admite rekeying aunque no es automático atm [23:43] se envían ACKs de vuelta en lotes (o sea "recibí todos los paquetes del mensaje 42 hasta el paquete 18 pero no el 3 o el 7") [23:44] (y la razón práctica por la que me fui por la impl UDP antes que la impl TCP es que UDP da E/S asíncrona 'gratis' con casi 0 overhead) [23:45] por supuesto [23:45] quedan dos cosas por hacer en esa impl udp: hacer station to station para MITMs y añadir un paquete para "oh mierda, olvidé la clave de sesión" [23:45] bien [23:46] después del transporte UDP el siguiente que quiero implementar es el HTTP por sondeo, así tendremos soporte tanto para el usuario común (UDP) como para el usuario con firewall/NAT/proxy (HTTP por sondeo) [23:47] ok, así que sí, eso hay que documentarlo en una spec :) [23:48] * jrand0m !se golpea por codificar antes de especificar [23:48] codificar antes de especificar me ayuda [23:48] sí, funciona mejor iterativamente [23:48] (porque encontramos problemas en las specs al implementarlas, etc.) [23:49] ok, eso es 3) specs. 4) administrivia [23:49] 4.1) anon cvs. thecrypto? :) [23:49] justo a tiempo [23:49] bueno, lo estoy mirando, creo que 2401 está bloqueado actualmente [23:49] ¿puedes cvs -d :pserver: localmente? [23:49] y puede que también haya que hacer algo de inetd, gracias jrandom [23:50] ah, coo' [23:50] déjame probar eso, olvidé que podías hacer eso :) [23:51] ¿sería solo cvs -d :pserver: ? [23:51] cvs -d :pserver:anonymous@localhost:/home/cvsgroup/cvsroot/ co i2p [23:52] además, sería genial si pudiéramos tener un bugzilla ahí también [23:52] acvs [checkout aborted]: connect to localhost(127.0.0.1):2401 failed: Connection refused [23:52] 'k, ¿después de añadir la línea de inetd.conf y kill -HUP identd? [23:52] déjame probar esa línea de inet y te digo [23:52] ejem, inetd :) [23:52] 'k, bien [23:53] ¿el pserver va en la misma línea? [23:53] sí, todo eso va en una línea [23:55] ok, eso es todo por administrivia, al menos lo que se me ocurre [23:55] 5a) co, tu turno [23:56] Cuando dos personas quieren registrar el mismo nombre de entidad, a la segunda se le rechaza. [23:56] Pero si usamos un enfoque basado en firma, [23:56] la persona a la que se le rechazó podría enviarle un mensaje al servidor de nombres [23:56] de todos modos, diciéndole que modifique el registro. [23:56] Hay dos posibilidades: [23:57] 1) La CA envía al servidor de nombres una copia de la clave pública de la entidad que fue aprobada. [23:57] 2) La CA envía a la persona que está registrando un nombre un certificado, firmado con su clave privada. El servidor de nombres tendrá la clave pública de la CA para verificarlo. [23:58] Si un usuario malicioso le dice al servidor de nombres que modifique cierto registro, la falta de un certificado evitaría la modificación. [23:58] Eso es lo que estaba pensando. [23:59] pero en ese caso la CA conoce la clave: la cripto asimétrica implicaría que la CA solo conozca la clave pública, además la CA nunca querría ni necesitaría dar esa clave pública a nadie: es solo para que el actualizador auténtico firme cuando solicite una actualización [00:00] lo que describes suena más a cripto simétrica, básicamente usar una frase de paso [00:00] ¡cvs me está fastidiando! [00:00] (donde el certificado es el secreto compartido entre las CAs y el propietario auténtico del nym) [00:00] *** mrsc (~efgsdf@anon.iip) se ha unido al canal #iip-dev [00:01] ¿qué pasa, thecrypto? [00:01] añadí el usuario anonymous con contraseña en blanco, lo añadí a readers y al cvsgroup y me sale cvs login: authorization failed: server localhost rejected access to /home/cvsgroup/cvsroot for user anonymous [00:01] jrand0m: Buen punto. Digamos que esta parte de la especificación no está finalizada, y pensaré un poco más en ello. [00:01] coo' [00:01] *** LeerokLacerta (~leerok@anon.iip) se ha unido al canal #iip-dev [00:02] Konnichiwa. [00:02] hmm thecrypto, no creo que quieras un usuario del SO llamado anonymous [00:02] hola, LeerokLacerta [00:02] Hola, jrand0m. [00:02] bueno, le puse una contraseña y ahora funciona [00:03] jrand0m: Y si tienes más sugerencias después de leer la spec, envíamelas. [00:03] lo haré, co [00:03] genial, thecrypto... ¿su shell es /bin/false? [00:03] ahora solo tengo que encontrar esa sección en el manual de cvs sobre cómo crear un usuario [00:03] -> *thecrypto* ¿cuál es el pw? [00:04] ahora lo es [00:05] ok, podemos resolver esto después de la reunión. [00:05] ok, último punto de la agenda: 5b) ? [00:05] ¿alguna pregunta / idea / preocupación? [00:05] solo revisad la app IM [00:06] ahora mismo todo lo que hace es crear un árbol, pero muestra cómo está empezando a verse [00:06] ¿Sin SOCKS? [00:06] ohh sí, eso es lo que olvidé [00:06] ah, genial, thecrypto [00:06] ¿SOCKS? ¿como en, el protocolo proxy? [00:06] ¿alguien aquí bueno haciendo iconos? [00:06] Sip. [00:06] La respuesta todas las veces que he preguntado ha sido "No". [00:07] ah. sí, definitivamente vamos a querer un proxy socks, pero nadie está trabajando en ello atm. [00:07] Hmm. [00:07] ese va a ser una de las apps que querremos para la 1.0 pública, para que la gente pueda navegar sitios basados en i2p, y también para que la gente pueda navegar la web normal anónimamente [00:07] hay suficientes proxies socks disponibles gratis, diría ;) [00:08]