Reunião de Desenvolvedores do I2P - 01 de fevereiro de 2005

13:06 <jrandom> 0) oi 13:06 <jrandom> 1) status do 0.5 13:06 <jrandom> 2) nntp 13:06 <jrandom> 3) propostas técnicas 13:06 <jrandom> 4) ??? 13:06 <jrandom> 0) oi 13:06 * jrandom acena 13:06 <+postman> oi jr 13:07 * postman acena 13:07 <jrandom> w3wt há vida lá fora :) 13:07 <jrandom> notas semanais de status publicadas @ http://i2p.net/pipermail/i2p/2005-February/000561.html 13:07 <ant> * dm acena 13:08 <jrandom> enquanto vocês leem aquele e-mail, podemos ir para 1) status do 0.5 13:08 <MANCOM> oi 13:09 <jrandom> muito progresso na última semana, toda a nova criptografia foi integrada e testada, e agora toda a operação de tunnel do router é feita através dos novos tunnel pools 13:10 <jrandom> ainda há algumas partes do router que eu tirei enquanto fazia a atualização, como a ligação para solicitar leases dos clientes ou testar periodicamente os tunnels, mas isso não deve ser muito difícil 13:11 <jrandom> o código não é compatível com a rede em produção, e está em um branch separado no cvs, então as pessoas ainda podem puxar o cvs HEAD e trabalhar com a versão mais recente 13:12 <+polecat> Dook finalmente olhei aquela página, e ainda não entendo como podemos evitar a redundância no estilo mixmaster para nos proteger de ataques de detecção de tunnel. 13:12 <+protokol> yey 13:12 <+polecat> Imagino que funcione muito bem, no entanto. :) 13:12 <+protokol> você está colocando mais alguma coisa legal que quebre compatibilidade? 13:13 <+protokol> o tunnel pool tem a ver com treads, né? 13:13 <jrandom> polecat: não verificamos a cada salto, mas temos um tamanho de mensagem fixo para impedir marcação útil (e tudo é criptografado em cada salto) 13:14 <jrandom> protokol: estou considerando http://www.i2p/todo#sessionTag 13:14 <+polecat> Então como evitar que múltiplos saltos fiquem repassando mensagens falsas e causem um DoS? 13:15 <jrandom> mas não, os pools não são a questão de threading, os pools só nos permitem gerenciar os tunnels com segurança para que não recebamos aquelas mensagens "Lease expired" e possamos configurar o comprimento por cliente 13:15 <jrandom> polecat: eles vão falhar no endpoint, e o criador vai detectar a falha e deixar de usá-lo 13:16 <+protokol> jrandom: além de qualquer dificuldade, acho que qualquer recurso que melhore o anonimato deve entrar o quanto antes 13:16 <+polecat> w00t! PRNG sincronizado! Primeira aplicação que já vi dessa ideia! 13:17 <ant> <dm> o que significa PRNG? 13:17 <ant> <dm> se me permitem perguntar :) 13:18 <jrandom> protokol: concordo, é para isso que serve o 0.5 :) não há outras frutas fáceis na camada i2p, mas sempre há melhorias a fazer nas camadas de app e lib (por exemplo, i2ptunnel filtering, etc) 13:18 <jrandom> dm: Gerador de Números Pseudoaleatórios 13:18 <ant> <dm> legal, obrigado 13:20 <+protokol> então você está dizendo que depois disso é basicamente ajuste de velocidade e confiabilidade? 13:21 <+protokol> e por que o IRC tem estado uma droga ultimamente 13:21 <jrandom> protokol: antes da 2.0 para o core e o router, sim 13:21 <+protokol> não consigo me conectar ao servidor do duck 13:21 <+protokol> yey 13:21 * jrandom não sabe, vimos talvez 5 desconexões em massa no último dia ou algo assim, talvez algo do lado do servidor 13:22 <jrandom> há muita coisa para ajustar, especialmente na lib de streaming depois que o 0.5 for implantado 13:23 <+polecat> Aquela coisa toda do UDP. 13:24 <jrandom> ah, a lib de streaming não deve precisar de mudanças para a versão 0.6, além das que fizermos para a revisão 0.5 13:25 <jrandom> ok, isso é tudo que tenho para trazer em relação ao status do 0.5 - alguém tem mais algo sobre isso? 13:27 <jrandom> se não, passando para 2) nntp 13:27 <jrandom> nntp.fr.i2p está no ar, confiram :) 13:28 <jrandom> Não parece que o LonelyGuy esteja por aqui, mas ele pode ser contatado em http://fr.i2p/. há também instruções de configuração para slrn no meu blog, e o jdot descobriu que o thunderbird pode ser relativamente seguro (embora eu não saiba que config o jdot usou) 13:30 <smeghead> LonelyGuy? :) 13:30 <cervantes> alguém também testou o Pan? 13:30 <jrandom> ele tem aparecido por aqui de vez em quando 13:30 <+polecat> Eu não gastaria muito tempo com nntp, mas contanto que tenha controle de acesso gerido pelo usuário, está ok. 13:30 <jrandom> (lonelyguy, não o pan ;) 13:30 <smeghead> achei que o nome dele fosse LazyGuy 13:31 <jrandom> é LazyGuy? 13:31 <jrandom> sei que já tivemos ambos... 13:31 <jrandom> você tem razão, lazyguy 13:31 * jrandom !se esfaqueia 13:31 <jrandom> cervantes: acho que o LazyGuy testou, porém não sei a config nem o resultado 13:32 <cervantes> Achei que era LimeyGuy? 13:33 * jrandom aguarda os comentários do SnarkeyGuy 13:33 <smeghead> ele é francês 13:35 <jrandom> ok, não tenho mais nada a acrescentar além disso, então, a menos que alguém tenha perguntas, passando para 3) propostas técnicas 13:35 <cervantes> smeghead: você está pensando no ParesseuxGuy 13:36 <jrandom> orion reuniu algumas boas descrições e ideias para algumas das questões mais complicadas em 1) status do 0.5 13:36 <jrandom> 2) nntp 13:36 <jrandom> 3) propostas técnicas 13:36 <jrandom> erg 13:36 <jrandom> droga ^C^V 13:36 <jrandom> lá em http://ugha.i2p/I2pRfc, isso sim 13:37 <jrandom> então, da próxima vez que quiser discutir como você tem uma ideia matadora de nomenclatura, vá para http://ugha.i2p/I2pRfc/I2pRfc0001ResourceNameMetadata 13:39 <jrandom> não tenho muito mais a acrescentar além disso. é um wiki, bora wikiar :) 13:39 <+polecat> Boa. 13:39 <+postman> jrandom: ohh, legal, acho que preciso adicionar algumas ... 13:40 <jrandom> legal, postman, imaginei que sim :) tem um template lá para novos 13:41 <+postman> jrandom: me dá um tempinho (primeiro o primeiro) mas eu vou contribuir :) 13:41 <jrandom> w3rd 13:41 <+polecat> ResourceNameMetadata, formar isso é relativamente trivial. O truque é descobrir como /obter/ isso de outras pessoas. 13:42 <jrandom> polecat: como disse o postman, primeiro o primeiro. 13:42 <+polecat> Mas se eu tivesse uma solução, eu estaria wikiando agora, não estaria? :) 13:42 <jrandom> heh 13:42 <jrandom> discutir os trade-offs de /como/ distribuir antes de decidir /o que/ distribuir é prematuro 13:43 <jrandom> há espaço para muitos, então qualquer um deve se sentir à vontade para postar ideias que ainda não estejam totalmente trabalhadas (embora as totalmente funcionais, com implementações, seriam legais também ;) 13:44 <jrandom> ok, a menos que haja mais algo sobre isso, talvez possamos passar para o bom e velho 4) ??? 13:44 <jrandom> alguém tem mais alguma coisa para trazer? 13:45 <jrandom> smeghead: há algo que as pessoas possam fazer para ajudar a resolver as questões do gcj, ou isso está parado por causa do prng deles? 13:46 <+polecat> O que distribuir é só um dict assinado. Simples assim. 13:46 <+polecat> É, provavelmente uma boa ideia. 13:46 <+polecat> Eu AINDA estou trabalhando no esqueleto do meu cliente bt de i2p, mas apreciaria muito conselhos em qualquer estágio. 13:46 <smeghead> acho que encontrei uma solução 13:46 <smeghead> no gnu crypto, há uma impl. do fortuna desde o último verão 13:46 <jrandom> legal, polecat 13:46 <jrandom> ah, legal, smeghead 13:46 <+polecat> smeghead: Hee, os $150 já são praticamente seus. 13:47 <smeghead> posso montar um gnu-crypto.jar que contenha apenas as classes necessárias para a Fortuna 13:47 <+polecat> Minhas notas de trabalho até agora estão em http://polecat.i2p/bittorrent.plan.doc 13:47 <smeghead> se distribuirmos o gnu-crypto.jar inteiro, dá cerca de 500 KB, realmente grande demais 13:47 <+polecat> Não deixe o .doc assustar você, é text/plain. 13:48 <+polecat> Fortuna não usa SecureRandom para fazer coisas aleatórias? 13:48 <jrandom> yowza, sim, 500KB é um pouco excessivo, mas olhando de relance para http://www.gnu.org/software/gnu-crypto/, parece algo que poderíamos integrar com segurança (já que apenas faríamos link, não modificaríamos) 13:48 <smeghead> SecureRandom nunca foi o problema 13:48 <jrandom> polecat: fortuna /alimenta/ o SecureRandom :) 13:49 <smeghead> jrandom: seria fácil fazer um .jar customizado, provavelmente em torno de 50KB 13:49 <smeghead> (estimativa grosseira, veja bem) 13:49 <smeghead> eu poderia fazer um build do ant para empacotá-lo sob demanda, inclusive 13:50 <jrandom> smeghead: quer colocar isso em i2p/apps/fortuna/ ? 13:50 <smeghead> farei isso 13:50 <jrandom> animal! 13:51 <smeghead> depois disso, assumindo que o gcj finalmente vai cuspir números aleatórios, provavelmente haverá mais testes de várias funcionalidades do i2p 13:51 <+polecat> Qual é a licença? 13:51 <jrandom> então podemos fazer um pouco de vudu em net.i2p.util.RandomSource para usar ou SecureRandom ou fortuna (se for encontrada, etc) 13:51 <smeghead> lgpl 13:51 <+polecat> Legal. 13:51 <smeghead> verdade, SecureRandom seria desnecessário 13:52 <jrandom> sim, ainda há muito a fazer para colocá-lo gcjing, mas é um ótimo começo 13:52 <jrandom> nos perfis que fiz na live net, reseedar o PRNG consome uma boa parte da carga de cpu 13:52 <smeghead> se alguém curte escrever testes 13:52 <smeghead> mas provavelmente não preciso terminar essa frase 13:52 <jrandom> hehe 13:53 <smeghead> vou perguntar ao maintainer do gnu crypto sobre essa impl., porque eu procurei no Google informações sobre ela e vasculhei os arquivos da lista deles e não há um pio sobre isso 13:54 <smeghead> e os logs de commit do cvs deles também não são muito elucidativos 13:54 <jrandom> 'k boa ideia 13:54 <smeghead> espero que funcione 13:54 <smeghead> está no cvs do kaffe btw 13:54 <smeghead> sua versão deve ter isso até 13:55 <jrandom> hmm, ah, sim, do import do gnu-crypto 13:55 <smeghead> gnu.security.prng.Fortuna 13:55 <jrandom> o provider do 'kaffe' ainda usa o sha1prng antigo deles, iirc 13:55 <jrandom> legal 13:56 <MANCOM> qual é o status das coisas do sam para .net? é para começar a mexer ou devemos esperar mudanças grandes? 13:56 <smeghead> MANCOM: precisa de testes, vou escrever alguns testes unitários para isso em breve 13:56 <smeghead> essa coisa do gcj meio que colocou isso em espera 13:57 <smeghead> MANCOM: não espero que haja quaisquer mudanças na API, então deve ser seguro programar em cima dela 13:58 <smeghead> mudanças por trás da API são prováveis, mas você, como cliente, não precisa saber disso :) 13:59 <MANCOM> :) 13:59 <jrandom> pode haver algumas atualizações posteriores que sejam relevantes se você construir apps que façam grandes transferências em massa 14:00 <jrandom> mas se você estiver transferindo apenas dezenas de KB por vez, deve ficar tudo bem 14:00 <smeghead> ok, se a API do cliente Java mudar, então a do sam-sharp também mudará :) 14:01 <MANCOM> não tenho como argumentar contra isso 14:02 <jrandom> ok, alguém tem mais alguma coisa para trazer para a reunião? 14:02 * cervantes baixa o Big Ben no canal 14:03 <+DrWoo> nota: bom trabalho jrandom 14:03 <smeghead> bom trocadilho, cervantes 14:03 * jrandom geme 14:04 <MANCOM> li que vocês não querem divulgar muito o i2p antes da v0.5, é verdade? 14:04 <jrandom> MANCOM: antes da 0.6. sim 14:04 <jrandom> MANCOM: 0.5 vai melhorar o anonimato e ajudar os usuários a controlar melhor seu desempenho. 0.6 vai permitir que milhares+ de usuários simultâneos operem com segurança 14:04 <MANCOM> ah. 0.6. ok. 14:05 <jrandom> gracias, doc, muito progresso :) 14:05 <+polecat> Whee, ansioso pela 0.6... 14:05 <+DrWoo> :) 14:06 <jrandom> concordo, polecat, concordo :) 14:06 * jrandom se prepara 14:06 * jrandom *baf* encerra a reunião