Reunião de desenvolvedores do I2P - 25 de outubro de 2005

16:24 <jrandom> 0) oi 16:24 <jrandom> 1) Estado da rede 16:24 <jrandom> 2) Integração do Fortuna 16:24 <jrandom> 3) Status do GCJ 16:24 <jrandom> 4) i2psnark está de volta 16:24 <jrandom> 5) Mais sobre bootstrapping 16:24 <jrandom> 6) Investigações de vírus 16:24 <jrandom> 7) ??? 16:24 <jrandom> 0) oi 16:24 * jrandom acena 16:24 <jrandom> notas semanais de status publicadas em @ http://dev.i2p.net/pipermail/i2p/2005-October/001079.html 16:25 * susi23 acena de volta 16:26 <jrandom> vamos direto para 1) estado da rede 16:26 <jrandom> como mencionei, as coisas parecem bem razoáveis até agora. 16:26 <+fox> <Romster> ah, reunião, ótimo 16:27 <jrandom> tem coisa boa chegando também, então teremos um novo lançamento no fim desta semana 16:27 <jrandom> alguém quer levantar algo sobre 1) estado da rede? 16:27 <@cervantes> omg 7 itens 16:27 <+legion> sim, está bonito :-) 16:27 <jrandom> semana puxada, cervantes :) 16:28 <@cervantes> só pode ser bom 16:28 <+Complication> Funciona relativamente bem, até o dev.i2p — consigo até fazer checkouts CVS sem mensagens de EOF. 16:28 <jrandom> legal :) 16:28 <+Complication> Pode ter sido sobrecarga relacionada ao lançamento, aquelas últimas. 16:28 <+Complication> Mas não posso afirmar. 16:28 <jrandom> o dev.i2p também está no código do build mais recente (-7), então deve estar com desempenho substantivamente melhor que antes 16:29 <jrandom> s/dev.i2p/cvs.i2p (etc)/ 16:29 <+legion> o forums.i2p também parece estar muito melhor que antes :) 16:29 <@cervantes> *ahem* 16:29 <+fox> <Romster> é seguro deixar outros entrarem no i2p etc.? 16:29 <+Ragnarok> ok, agora tenho que testar esse milagroso "cvs checkout que funciona de primeira" 16:30 <+fox> <Romster> já que não há limites conhecidos agora 16:30 <@cervantes> isso porque todo mundo está martelando a i2p-list em vez de postar no fórum 16:30 <+legion> hmm tem certeza, cervantes? 16:30 <jrandom> Romster: bem, temos crescido num ritmo bom ultimamente, mas devemos adiar a beta pública até a 0.6.2 16:30 <jrandom> heh cervantes ;) 16:30 <jrandom> psiu, Ragnarok, vai zicar isso! 16:31 <+Ragnarok> uau... é verdade. Estou sem palavras 16:31 <+fox> <Romster> ok, jrandom 16:31 <jrandom> (cara, meus olhos estão lacrimejando por causa do curry que meus colegas estão cozinhando lá embaixo) 16:31 <jrandom> boa, Ragnarok 16:32 <+fox> <Romster> lol isso sim é curry forte 16:32 <jrandom> ok, se não houver mais nada em 1), podemos passar rapidamente para 2) Integração do Fortuna 16:32 <jrandom> (verdade, Romster) 16:32 <+fox> <shardy> viva a integração do Fortuna! 16:32 <+fox> <Romster> indo para 2) :P 16:32 <+fox> <Romster> o que é Fortuna? 16:32 <jrandom> heh achei que você ia gostar, shardy :) 16:32 <+fox> <Romster> fiquei um pouco para trás no último mês 16:32 <+Complication> algoritmo PRNG (gerador pseudoaleatório), se não me engano. 16:33 <+Complication> Supostamente um bom, pelo que escrevem. :P 16:34 * Complication não sabe nada sobre o funcionamento interno, porém 16:34 <jrandom> shardy: adoraria se você pudesse dar uma olhada quando puder 16:34 <+fox> <shardy> claro 16:34 <+fox> <shardy> vocês estão usando a implementação do GNU? 16:34 <jrandom> Romster/Complication: há alguns links no e-mail 16:34 <jrandom> sim, shardy - http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/core/java/src/gnu/crypto/prng/Fortuna.java 16:35 <jrandom> (integrado com http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/core/java/src/net/i2p/util/FortunaRandomSource.java ) 16:36 <jrandom> mas nós diferimos da implementação gnu-crypto pura, já que já temos código de AES256 e SHA256 (do Cryptix e do Bouncycastle, respectivamente) 16:36 <jrandom> ok, de qualquer forma, isso parece legal, pois estamos mexendo para colocar esse suporte aí faz provavelmente um ano 16:37 <jrandom> (a integração do Fortuna foi um dos principais projetos que motivaram o smeghead a criar o 'pants' ;) 16:37 <jrandom> se alguém tiver perguntas/comentários/preocupações sobre isso, por favor jogue na lista 16:37 <jrandom> (ou e-mail, ou fórum, claro) 16:38 <+fox> <Romster> sim, cadê o smeghead, ele não aparece já faz um tempo 16:38 <jrandom> smeghead está [redacted] fazendo [redacted] 16:39 <jrandom> ok, passando para 3) status do GCJ 16:39 <jrandom> i2p funciona no GCJ! [w00t!] 16:39 <+susi23> bom trabalho 16:39 <+legion> sensacional 16:39 <jrandom> pelo menos funciona no GCJ 4.0.2 no Linux 2.6.12. Não testei em outras plataformas 16:40 <jrandom> sim, o pessoal do GCJ e do GNU Classpath fez milagres 16:40 <jrandom> foi bem fácil compilar, aquelas classes de referência estática de que eu lembrava não foram necessárias 16:41 <+Complication> O que soa bem positivo, dada a abertura não tão completa do Java da Sun (quanto à distribuição, se lembro bem). 16:41 <jrandom> agora há um makefile distribuído com o I2P, embora, por simplicidade, eu ache que provavelmente vamos continuar distribuindo Java puro, pelo menos principalmente 16:41 <+susi23> (depois tentamos rodar em J2ME ;) 16:42 <+fox> <Romster> GCJ para substituir a JVM da Sun> 16:42 <cat-a-puss> como está o desempenho com o GCJ? 16:42 <jrandom> sim, embora a Sun seja totalmente aberta, e nós /poderíamos/ distribuir a JVM deles junto com o I2P, a licença deles proíbe distribuir a JVM como uma ferramenta de propósito geral 16:42 <jrandom> cat-a-puss: comparável 16:42 <jrandom> a maior parte do trabalho pesado no i2p já é feito por código em assembly ;) 16:43 <+fox> <Romster> como ficaria o i2p com C#/mono de novo, com aquela adição de Java para C# (esqueci o nome) 16:43 <+fox> <Romster> lembro que o jrandom e eu testamos isso há tempos 16:43 <jrandom> sem ideia. mas se funciona com gcj, pode funcionar com ikvm — aquela coisa de JVM do mono 16:44 <+Ragnarok> IKVM 16:44 <+Ragnarok> deixa 16:44 <+fox> <Romster> ah esse mesmo, ikvm 16:44 <+fox> <Romster> muitas diferenças entre GCJ, IKVM e o da Sun? 16:45 <jrandom> nunca usei ikvm 16:45 <+fox> <Romster> tenho certeza que você já usou com mono ou era o eclipse? 16:45 <+fox> * Romster dá de ombros 16:45 <jrandom> e o i2p como é distribuído atualmente não suporta a console do router, embora suporte a operação do router, i2ptunnel e sam 16:46 <+Ragnarok> o que está bloqueando a console do router? 16:47 <+susi23> xerces, se bem me lembro 16:47 <jrandom> coisas do xerces. o xercesImpl que vem com o i2p tem dependências de sun.*, e quando tentei ingenuamente colocar o xerces mais recente, GCJear aquilo e o jdom e o rome e o resto do jetty estava b0rkando 16:47 <jrandom> parece que a versão mais recente do xerces tem alguns requisitos adicionais 16:48 <jrandom> (para arquivos jar que atualmente não distribuímos). porém, tenho certeza de que conseguimos resolver 16:49 <+fox> <Romster> jrandom é bom em rastrear problemas :) 16:49 <jrandom> ainda melhor em criar problemas 16:49 <+fox> * Romster pega um café 16:49 <jrandom> ok, mais algo em 3) status do GCJ? 16:49 <jrandom> ou vamos para 4) i2psnark 16:50 <jrandom> considere que fomos 16:50 <jrandom> ok, i2psnark está de volta (yay) 16:51 <jrandom> não tenho muito a acrescentar ao que está no e-mail... tem algo, Ragnarok? 16:51 <+Ragnarok> não 16:51 <+susi23> sobre o frontend web 16:51 <+Ragnarok> mais testes seriam bons, então todos deveriam experimentar :) 16:52 <+susi23> dar suporte a isso com o susibt não deve ser problema 16:52 <jrandom> ooh conta pra gente, susi23 :) 16:52 <jrandom> legal 16:52 <+fox> <jme___> pergunta ingênua, por que gastar tempo dando suporte a um cliente bt antigo enquanto outro (azureus) oferece um cliente completo? 16:52 <jrandom> jme___: o azureus *é* animal 16:52 <+susi23> um lançamento principal do susibt está previsto para novembro :) 16:53 <jrandom> heh legal, susi23 16:53 <+Complication> Para mim, o Azureus pareceu terrivelmente complexo. 16:53 <+Ragnarok> azureus é uma porcaria 16:53 <+susi23> para mim, sempre preciso de uma solução headless (sem interface) 16:53 <+Ragnarok> sem rodeios 16:53 <+fox> <jme___> ok :) 16:53 <jrandom> jme___: o azureus é um pouco pesado, porém é uma ótima solução bt de uso geral 16:53 <+Complication> (eu, pessoalmente, consigo imaginar o dia em que eu misconfiguro algo nele e prejudico meu anonimato.) 16:54 <+fox> <jme___> faz sentido, só queria saber 16:54 <+fox> <Romster> pra mim o azerious nunca funcionou bem, mudei para o bitlord que funciona 16:54 <jrandom> ainda pretendo ajudar a melhorar o plugin azneti2p com o pessoal do azureus, mas o i2psnark levou literalmente menos de 2 horas até eu estar fazendo swarm de dados 16:54 <+legion> É, o azureus é grande demais e complicado para o i2p 16:54 <+Complication> Se a meta é empacotar um cliente bt junto com o i2p, um cliente leve parece o melhor. 16:54 <+fox> <Romster> princípio KISS 16:54 <+Ragnarok> Eu gosto mais do cliente oficial, mas o i2psnark tem a grande vantagem de ser simples o suficiente para eu hackear 16:55 <+legion> a questão é que o i2p não precisa de um cliente bittorrent pesado 16:55 <jrandom> sim, o código é bem limpo (com aquela formatação GNU esquisita ;) 16:55 <+Ragnarok> maldito gnu 16:55 <+Ragnarok> o pior estilo de chaves de todos 16:55 <jrandom> heh 16:55 <+fox> <Romster> heh um reformatador de código :) 16:55 <+Ragnarok> o jrandom não me deixa :) 16:55 <+Ragnarok> bem, com razão 16:55 <+fox> <jme___> independência e simplicidade são critérios com os quais eu definitivamente concordo 16:56 <+fox> <Romster> haverá opções para habilitar o programa bt-torrent em cada nó i2p? 16:56 <jrandom> sim, seria legal se pudéssemos backportar multitorrent, seleção de peças e capacidade web para o snark principal do mjw 16:56 <+Ragnarok> quanto mais simples for, maior a chance de ser mantido 16:56 <jrandom> exaaatamente, Ragnarok 16:57 <+legion> sim, backportar isso seria sensacional 16:57 <+fox> <Romster> fora de tópico: deem uma olhada na rede KAD do emule, acho bem legal. 16:57 <jrandom> Romster: agora ele vem no build por padrão, mas assim que colocarmos no susibt, vai ficar na navegação superior com o resto dos clientes 16:58 <+Ragnarok> precisamos poder distribuir também um gerador de .torrent. E um tracker seria legal. 16:58 <jrandom> sim, na verdade, o snark tem ambos, eu só desativei porque não queria mantê-los :) 16:58 <+legion> hmm bom ponto, ragnarok 16:58 <jrandom> mas reativá-los não seria muito trabalho 16:59 <+Ragnarok> bem, o gerador de torrent pelo menos não deve ser tão ruim 16:59 <jrandom> há um Tracker.java também, e tratamento no PeerAcceptor, mas eu joguei fora o que não era necessário, então provavelmente seria bom olhar em http://klomp.org/snark/ para isso 17:00 <jrandom> (e revisar http://dev.i2p/~jrandom/snark_diff.txt para as mudanças) 17:00 <+fox> <Romster> já que o snarik voltou, vão trabalhar nele, certo? :) 17:00 <+legion> na verdade, quando se trata de um tracker, seria melhor chegar a uma solução distribuída 17:00 <+fox> <Romster> snark* 17:00 <jrandom> portar código é mais fácil do que construir um novo tracker distribuído, legion ;) 17:00 <+fox> <Romster> legion, isso sim que é falar 17:00 <+legion> verdade 17:01 <jrandom> mas eu não seria contra integrar uma solução de tracker distribuído, limpa, mantida e amigável ao anonimato :) 17:01 <+fox> <Romster> poderia ser anexado aos eepsites? 17:01 * jrandom vê um pônei voador passar pela janela 17:01 <+Ragnarok> o cliente bt oficial tem um tracker distribuído baseado em Kademlia, mas obviamente isso só serve como referência de design 17:01 <+legion> um ponto de partida ;) 17:02 <+fox> <Romster> na verdade Kademlia = rede KAD do emule? hmm, se for o caso, KAD seria ideal para um tracker, mas o bootstrapping é um problema 17:03 <+Ragnarok> são baseados no mesmo algoritmo, mas não são compatíveis de forma alguma 17:03 <+Ragnarok> compatíveis, aliás 17:04 <+Ragnarok> fazer algo como o KAD do emule para o i2phex seria interessante... 17:04 <+Ragnarok> enfim, pôneis voadores 17:04 <jrandom> :) 17:04 <jrandom> (concordo com ambos) 17:04 <jrandom> ok, mais algo em 4) i2psnark? 17:05 <+Ragnarok> enquanto tivermos algo para criar arquivos .torrent, os trackers existentes estão ok 17:05 <jrandom> bom ponto — acho que há algum código comentado no main do Snark 17:05 <+legion> não, acho que os trackers existentes não estão ok :( 17:05 <jrandom> o que há de errado com eles, legion? 17:05 <cat-a-puss> não basta entregar aos usuários um arquivo torrent 17:05 <+legion> com frequência há dificuldade para acessá-los 17:06 <jrandom> hmm cat-a-puss? ah, você quer dizer que precisamos de uma interface web para fazer swarm de forma transparente? 17:06 <+legion> os sites ficam inundados de tráfego 17:06 <jrandom> ah, isso é um problema do i2p, com sorte a 0.6.1.4 vai melhorar isso 17:06 <jrandom> o postman estava me contando que estava recebendo toneladas de hits em tracker.postman.i2p 17:06 <jrandom> esqueci os números de cabeça 17:06 <cat-a-puss> se estamos cuidando tanto do código de swarm quanto do código para obter o torrent, melhor tornar isso transparente para o usuário 17:07 <jrandom> o orion.i2p/bt/ não é muito usado, porém 17:07 <jrandom> (e o tracker-fr parece bem ativo) 17:07 <+susi23> com o susibt espero incluir o feed RSS dos trackers, assim você não precisa mais ir à página dos trackers e os torrents são baixados automaticamente :) 17:07 <cat-a-puss> também evita confundir um torrent do i2p com um não anônimo 17:07 <+fox> <jme___> o tracker HTTP para bt não escala devido ao protocolo mal projetado 17:07 <+fox> <Romster> watchdog do router: router travou feio, reinício forçado, wtf 17:07 <+legion> certo, que é meu ponto: alguns trackers ficam sobrecarregados enquanto outros ficam ociosos 17:07 <jrandom> cat-a-puss: ah, sim, eu adoraria integrar ganchos do syndie no susibt :) 17:07 <+fox> <jme___> isso pode ser facilmente corrigido, mas quebraria a compatibilidade com o protocolo bt oficial 17:08 <+fox> <jme___> é o caminho seguido pelas coisas de tracker via DHT 17:08 <jrandom> (e o contrário também, para as pessoas poderem sindicar arquivos .torrent com facilidade, etc.) 17:08 <+Complication> Romster: também tenho isso, mas a máquina onde acontece é no limite (300 MHz) 17:08 <+fox> <Romster> o tracker distribuído é a solução para trackers martelados 17:08 <jrandom> legion: isso pode ser facilmente remediado se as pessoas usarem trackers diferentes :) 17:08 <+fox> <Romster> DHT do azerius 17:08 <jrandom> código é caro, usar URLs diferentes é barato 17:08 <+legion> sim, mas não parecem estar fazendo isso, fazem? 17:09 <jrandom> mas, sim, um tracker distribuído seria ótimo. não está no meu roadmap, porém, mas se alguém fizer andar, seria Fera. 17:09 <+Complication> No tempo devido... certamente alguém pode ir para distribuído também. 17:09 <+legion> Em vez de postar torrents em sites de tracker, poderiam postar um bith e os detalhes no seu eepsite. 17:10 <jrandom> bith == hash? 17:10 <+legion> sim, significa bittorrent hash, não é termo meu 17:10 <+Complication> No começo, porém... um cliente simples e sólido, em Java, empacotado com o router... pode resolver muitos problemas. (Talvez até buscar atualizações assinadas sem sobrecarregar o dev.i2p.) 17:11 <+legion> sim, seria ótimo 17:11 <jrandom> isso aí, Complication 17:11 <+fox> <Romster> sim, atualizações via torrent 17:11 <+fox> <Romster> ok, próximo item da lista :) 17:12 <jrandom> ok, 5) mais sobre bootstrapping 17:12 <+legion> sim, vamos em frente 17:12 <jrandom> muita coisa interessante na lista ultimamente, e não vou resumir tudo aqui :) 17:12 <+fox> <Romster> bootstrapping do banco de dados do router do i2p? 17:12 <jrandom> alguém tem perguntas/comentários/preocupações que queira discutir sobre o tópico? 17:12 <jrandom> Romster: veja a lista e/ou o e-mail 17:12 <+fox> * Romster precisa ler essa lista 17:13 <jrandom> sim, tem coisa boa lá :) 17:13 <+fox> <Romster> tenho estado bem ocupado ultimamente 17:13 <+Complication> 26 mensagens para ler, não posso comentar ainda 17:13 <jrandom> ainda sem resultado final, mas estamos mirando uma nova forma de construir tunnels para a 0.6.2 17:14 <+fox> <Romster> uma forma nova, há uma falha no método atual? 17:14 <+fox> <Romster> falha* 17:14 <jrandom> a análise do Michael mostra que o ataque não é realmente um problema agora, pois há ataques mais fáceis nas alternativas 17:14 <jrandom> leia a lista ;) 17:14 <+fox> <Romster> arg depois 17:14 <+fox> <Romster> agora é agora :) 17:15 <+fox> <Romster> normalmente eu estou dormindo a essa hora. 17:15 <+fox> <Romster> então raramente consigo estar numa reunião 17:16 <cat-a-puss> você pode postar suas ideias para uma forma nova / existentes / rejeitadas em um e-mail para a lista para podermos comparar 17:16 <+fox> <Romster> então tem a ver com métodos de ataque e criação de tunnels, suponho, sem ter lido a lista ainda 17:16 <cat-a-puss> (isso é para o Jrandom) 17:16 <jrandom> cat-a-puss: não tenho certeza se realmente concluímos um resultado final ainda 17:16 <+fox> <Romster> seria uma ideia, cat-a-puss 17:17 <+Complication> Romster: sim, era mais ou menos sobre dar ao endpoint de um exploratory tunnel menos influência como possível atacante 17:17 <jrandom> mas http://dev.i2p.net/pipermail/i2p/2005-October/001073.html é o mais recente do que vejo saindo da sua sugestão 17:17 <jrandom> bem, não influência — o i2p é uma mixnet de rota livre — mas menos informação 17:18 <+Complication> Sim, esse seria provavelmente um termo mais correto 17:18 <jrandom> (a URL acima está cheia de suposições, nenhuma cripto sólida definida ainda) 17:18 <+fox> <Romster> menos = melhor para mais robustez contra ataques, entendi o que você quer dizer 17:18 <jrandom> ((mas acho que dá para fazer tudo com técnicas existentes) 17:19 <jrandom> Romster: aqui está um gráfico do ataque do Michael contra o algoritmo existente, com o eixo X dizendo qual % da rede está comprometida - http://dev.i2p.net/~jrandom/fraction-of-attackers.webp 17:20 <jrandom> (a construção telescópica simples ficaria fora do gráfico antes de chegar em x=200) 17:20 <jrandom> ((então o que temos agora é literalmente ordens de magnitude melhor)) 17:20 <jrandom> mas podemos melhorar ainda mais 17:21 <jrandom> embora também exista a alternativa de garlic routing 17:21 <jrandom> enfim, sim, mais coisas para acertar, fiquem de olho na lista :) 17:21 <+fox> <Romster> ok, vou dar uma boa lida nessa lista depois 17:22 <+fox> <Romster> e ver se consigo pensar em algo para acrescentar 17:22 <jrandom> legal 17:22 <cat-a-puss> o método telescópico "novo" seria rápido o suficiente para fazer construção sob demanda? 17:22 <jrandom> não sei se queremos isso 17:22 <jrandom> é a questão de O(1) vs O(N) 17:23 <jrandom> a técnica nova permitiria criar tunnels sem usar os exploratory tunnels, deixando os exploratory tunnels para operação do netDb 17:23 <jrandom> (e para criação de exploratory tunnels :) 17:24 <+fox> <Romster> hrmm valeria a pena confundir os hackers dando a eles um monte de falsos positivos, mascarando a fonte real 17:24 <+legion> soa bem :) 17:24 <+legion> acho que uma bagunçada dessas seria boa 17:24 <cat-a-puss> jrandom: certo, eu estava perguntando se fazer isso aceleraria o suficiente, de modo que às vezes os últimos hops não saibam que são o último hop, como discutido na lista. 17:25 <+fox> <Romster> exploratory tunnels para coletar referências de router do netDB? 17:25 <jrandom> romster: nós somos os hackers ;) mas sim, se os falsos positivos superarem os verdadeiros, seria necessário um número substancialmente grande de ataques para obter dados estatisticamente significativos 17:26 <jrandom> hmm certo, cat-a-puss, mas não sei como isso aceleraria as coisas, nos moveria de uma topologia de tunnel O(1) para O(N) 17:26 <jrandom> ou o que você quis dizer com acelerar as coisas? 17:26 <+fox> <Romster> e se chegasse ao ponto de ser detectado, poderia então sumir e ficar em silêncio por um tempo? 17:26 <jrandom> usar a técnica nova certamente reduziria as criações de tunnel que falham 17:26 <+fox> <Romster> ou mudar a chave no meio e continuar ou algo assim heh 17:26 <jrandom> romster: provavelmente vale a pena fuçar os e-mails para revisar o ataque ;) 17:27 <+fox> <Romster> sim, depois de dormir 17:27 <+Complication> Romster: até onde sei, é um ataque principalmente passivo, então o alvo não consegue detectar que está ocorrendo 17:27 <+fox> <Romster> e consertar o PC de um amigo que tenho aqui 17:27 <+fox> <Romster> ah entendi, Complication. 17:27 <cat-a-puss> jrandom: não estou falando da coisa O(n). Quero dizer apenas esperar para construir um client tunnel até precisarmos de um para alguns apps, em vez de deixá-los lá o tempo todo. 17:28 <+Complication> (mas posso estar errado, e aquelas últimas 26 mensagens podem ter componentes ativos) 17:28 <+fox> <Romster> um ataque passivo de longo prazo acabaria encontrando o alvo? 17:28 <+fox> <Romster> vou comentar depois de ler a lista 17:28 <jrandom> ah, cat-a-puss, certamente vamos melhorar o pool de tunnels para a 0.6.2. atualmente só construímos o tunnel quando precisamos (dando-nos um tempinho caso a criação falhe) 17:28 <+Complication> Romster: bem, continuar o ataque além da vida útil do tunnel exigiria recursos e paciência 17:28 <+fox> <Romster> e entender melhor 17:29 <+Complication> Mas o tempo influencia toda probabilidade de sucesso. Você tenta por mais tempo, ganha mais chances. 17:29 <+fox> <Romster> ah, a ideia é a vida do tunnel ser curta demais para um ataque realmente valer a pena. 17:29 <jrandom> cada pool tem um número definido de tunnels de backup, e por padrão construímos substitutos entre 60-120 segundos antes de um antigo expirar 17:29 <+fox> <Romster> tempo* 17:30 <jrandom> certo, Complication — cada amostra ocorre apenas 'm' vezes a cada (c/n) tunnels 17:30 <+fox> <Romster> não há interação entre cada tunnel para coletar estatísticas? 17:30 <+fox> <Romster> enquanto um está prestes a morrer e outro está sendo construído 17:31 <jrandom> romster: os novos tunnels não conversam entre si, não, mas esse não é o ataque que o Michael tem descrito 17:31 <jrandom> há incontáveis ataques por aí, a maioria dos quais já tratamos, mas sempre que alguém aparece com um que possa afetar a operação do I2P, queremos analisar melhor 17:31 <+fox> <Romster> tenho que ler a lista, ok vou deixar por isso agora, mais alguém tem algo a dizer? 17:32 <jrandom> ok, se não houver mais nada, vamos para 6) investigações de vírus 17:32 <+fox> <Romster> na verdade uma estatística que vejo que poderia ser coletada é: sem 0 hop significaria que o próximo hop não é o endpoint, então poderia ser descartado, mas com milhões de nós essa técnica de análise seria inútil 17:33 <jrandom> não tenho nada a acrescentar além do que foi discutido no fórum 17:33 <jrandom> certo, Romster, há ataques de predecessor sobre o comprimento do tunnel, que é uma das principais coisas que estamos tratando na 0.6.2 17:33 <+fox> <Romster> vírus, que vírus? se for Linux, vai ser inexistente, mas Windows hmmm 17:34 <+Complication> Bem, embora eu não tenha conseguido construir um binário idêntico (vai saber por quê) a diferença final foi pequena o suficiente... para, com sorte, ser útil a quem se interessa por ler código assembly. 17:34 <jrandom> Romster: por favor, as notas semanais de status devem explicar esses itens da pauta, e a reunião é para discutir coisas /além/ do que está nas notas ;) 17:35 <+Complication> Não consegui encontrar nada óbvio ali, mas também não consegui explicar todas as diferenças. 17:35 <@cervantes> rtfml e rtff 17:35 <+fox> <Romster> é, não tenho acompanhado há um bom tempo, desculpa por isso, jrandom 17:35 <@cervantes> ;-) 17:35 <jrandom> sim, o fato de que tanto um arquivo .bat conhecido como seguro quanto o antigo acionaram o mesmo código de detecção é significativo 17:35 <+Complication> Sim, isso ajuda a diminuir as dúvidas. 17:36 <+Complication> Acho que o QBFC pode ter diferenças não documentadas dentro do mesmo número de versão (builds diferentes?) 17:37 * jrandom não faz ideia, mas pode ser só alguma interação com o SO, ou algo assim. Não sei, você publicou análise suficiente para as pessoas tomarem sua decisão informada 17:37 <+Complication> Acho melhor assim. 17:37 <+Complication> Desmontagem (disassembly) está bem fora do meu terreno usual. 17:37 <jrandom> legion: tem algo que você queira mencionar sobre isso, ou as pessoas devem ir ao fórum se quiserem mais informações? 17:38 <@cervantes> posso só reiterar o que outros disseram no fórum, e agradecer ao Complication pelo tempo e pelas tentativas meticulosas que ele dedicou para verificar essa questão 17:38 <jrandom> sim, é muito apreciado 17:38 <+legion> Não tenho nada a acrescentar, sinto que já falei demais sobre isso 17:39 <jrandom> 'k entendido. ok, mais alguém tem algo sobre isso, ou vamos para 7) ??? 17:39 <jrandom> [considere que seguimos] 17:40 <+fox> * Romster endossa isso :) 17:40 <+legion> ok, para 7)??? que tal tirarmos um momento para discutir i2phex 17:40 <jrandom> legal, boa ideia 17:40 <+fox> <Romster> já que estou usando agora mesmo :) 17:40 <@cervantes> não, não, abraço coletivo primeiro 17:40 <jrandom> redzara mencionou que estaria na reunião, mas o progresso no merge está lento 17:41 <+legion> susi23 perguntou sobre uma versão headless (sem interface) 17:41 <jrandom> ah, legal, vi seu post sobre isso 17:42 <+fox> <Romster> posso acrescentar que a lista de favoritos precisa ser mais larga para lidar com as chaves i2p mais longas 17:42 <+susi23> (não é obrigatório, eu só estava curioso) 17:42 <jrandom> bem, ninguém consegue lembrar chaves base64, então não sei se você está perdendo muito, Romster ;) 17:42 <jrandom> (e os primeiros bytes devem bastar para identificá-las unicamente) 17:42 <+fox> <Romster> iniciar o i2phex com um servidor é o maior problema que vejo até agora 17:42 <+legion> Na verdade eu gostaria de ver só os primeiros 12 caracteres das chaves exibidos no cliente 17:42 <+fox> <Romster> heh adivinha 17:43 * Complication está infelizmente muito ocupado e não consegue fazer xml-rpc 17:43 <jrandom> parece razoável, legion 17:43 <+fox> <Romster> e se exibir caracteres suficientes para tornar a chave única 17:43 <jnymo_> Estou tendo bons resultados com o i2phex 17:44 <jrandom> legal, jnymo_, tenho ouvido coisas boas também 17:44 <+fox> <Romster> então se 2 chaves começarem com abc será abcx 17:44 <jnymo_> 12 caracteres idênticos não é provável, Romster 17:44 <+fox> <Romster> verdade 17:44 <+Complication> Além disso, mais simples = mais rápido 17:44 <+fox> <Romster> mas não precisaria de 12 se as chaves forem tão aleatórias assim 17:45 <+Complication> (não que haja muito ganho de velocidade em exibir coisas) 17:45 <+legion> Talvez pudesse haver uma nova janela de propriedades do host, mostrando a chave completa e algumas informações como quanto está compartilhando e tal 17:45 <+susi23> (o netdb funciona muito bem com apenas 4 caracteres para IDs de router) 17:45 <+fox> <Romster> ou o banco de dados usando keyname=base64 e exibindo apenas o keyname 17:45 <jrandom> hmm, achei que já havia uma tela de informação do peer, legion? 17:46 <jrandom> legion: coisas assim seriam boas para adicionar ao phex principal, provavelmente? 17:46 <+legion> hmm pode ser... 17:46 <jrandom> (assim o Gregor pode manter ;) 17:46 <+Complication> Bem, há uma função "Browse host", mas pode não ser exatamente a mesma coisa. (Se funcionar.) 17:46 <jrandom> Complication: funciona 17:46 <jrandom> (funciona, quero dizer) 17:47 <+Complication> Parece basicamente colocar a destkey do host na caixa de busca 17:47 <+Complication> ...e executar uma busca. 17:48 <jnymo_> pode ser um assunto do i2phex principal, mas não vi um ETA para os downloads do i2phex 17:48 <+Complication> Hmm... ou na verdade, não executa uma busca. 17:48 <+Complication> O meu parece esperar até eu iniciar manualmente. 17:48 <+fox> <Romster> para que serve a caixinha "nearby i2phex running"? 17:49 <+legion> Vejo que há muito espaço para melhorias. ;) 17:49 <jrandom> sim :) 17:50 <jrandom> muita coisa a fazer, e o fórum é um bom lugar para postar ideias/sugestões/perguntas(/patches :) 17:50 <+fox> <Romster> apesar do nome óbvio 17:50 <jrandom> ok, alguém tem mais alguma coisa para a reunião? 17:50 <+fox> <Romster> hmm bom ponto 17:50 <+fox> <Romster> não consigo pensar em mais nada 17:51 <+fox> <Romster> mas alguém está trabalhando em um data store distribuído? 17:51 * cervantes olha o relógio 17:51 <+fox> <Romster> tipo ativamente 17:51 <jrandom> Romster: além do syndie, não 17:51 <jrandom> (não que eu saiba, pelo menos) 17:52 <+legion> bem, eu estava pensando em integrar um gerenciador de downloads HTTP ao i2p, facilitaria baixar conteúdos maiores de eepsites. 17:52 <+fox> <Romster> q e iphex e um ou dois outros, mas não vi nada mantido há um tempo já 17:52 <@cervantes> qual o status do feedspace... não ouvi nada sobre faz um tempo 17:52 <jrandom> legion: seria legal — acho que há um post sobre isso no fórum também 17:53 <+fox> <Romster> ah, feedspace, mais um 17:53 <jnymo_> se isso já foi mencionado na reunião, deixa... mas há novidades sobre a colaboração i2p freenet? 17:53 <jrandom> cervantes: da última vez que ouvi, o frosk estava meio ocupado, mas se o frosk estiver por aí, talvez possa nos contar mais :) 17:53 <+legion> Pessoalmente eu gostaria de ver uma colaboração i2p entropy. 17:54 <+fox> <Romster> tenho ideias para um datastore, mas seria uma expansão de métodos existentes que estão em uso atualmente 17:54 <+legion> Dado que q, feedspace e afins não parecem estar indo muito longe agora 17:54 <jrandom> jnymo_: eu mandei para o pessoal do freenet algum código para rodar no nosso transporte SSU, o toad tem participado de algumas discussões, mas o freenet não estará em posição para rodarmos como um data store em cima do i2p por um tempo (provavelmente depois que sair o release 0.7 deles) 17:54 <+fox> <Romster> quero começar um projeto mas não refazer o que outros já fizeram 17:54 <+legion> será que daria para portar o entropy para rodar sobre o i2p... 17:54 <jrandom> legion: entropy seria bom, mas a integração é meio difícil. claro, as pessoas poderiam rodar coisas como o fproxy.i2p para o entropy 17:55 * jrandom não conhece nada do código de transporte do entropy 17:55 <+fox> <Romster> congelei meu cliente de irc, já tem muitos em andamento; tudo que o i2p precisa agora é um datastore e ele vai superar o freenet com facilidade :) 17:55 <jrandom> (mas talvez seja uma boa forma de conseguir alguém para hackear no SDK do GCJ :) 17:56 <jrandom> Romster: ajudar em outros esforços é muito mais gratificante do que começar projetos novinhos, pois você faz muito mais com menos esforço :) 17:56 <jnymo_> ah.. parabéns pelo port no gcj 17:56 <+fox> <Romster> o entropy é em C ou C++, se bem me lembro 17:57 <jrandom> certo, Romster, por isso eles poderiam usar o SDK e a streaming lib do I2P, compilados com GCJ em bibliotecas nativas 17:57 <+fox> <Romster> jrandom, verdade, mas quem :) 17:57 <jrandom> eu não 17:57 <+legion> ah, e sobre outro assunto, só queria mencionar que hoje lancei uma nova versão da minha atualização do readme.html para a console do router i2p. 17:57 <jrandom> (a única maneira de fazer algo de que você se importa é *você* fazer :) 17:57 <jrandom> legal 17:57 * dust gostaria de ver algum tipo de syndication 'squid' para aliviar eepsites 17:58 <jrandom> dust: sim, total, se conseguirmos colocar o sucker nessa posição, seria ideal 17:58 <jrandom> por exemplo, eu adoraria obter as últimas infos do orion no syndie, local 17:58 <+fox> <Romster> construir um proxy para o squid usar :) 17:59 <+legion> Eu vinha adiando na esperança de que certas melhorias no python eepsitechecker já tivessem sido feitas. 17:59 <dust> ah, syndie 17:59 <jrandom> (na verdade é para isso que o syndie serve — syndication para reduzir a carga) 17:59 <dust> a resposta 17:59 <jrandom> há um verificador de eepsite em python? 17:59 <+fox> <Romster> é a primeira vez que ouço falar disso 17:59 <+legion> sim, é o que eu uso ;) 18:00 <jrandom> legal, legion 18:00 <+legion> sério? Existe há um tempo 18:00 <+fox> <Romster> legal, eu gostaria de ver isso :) 18:00 <@cervantes> acho que alguém portou o script do baffled... não lembro quem/quando 18:00 <+fox> <Romster> estou aprendendo python 18:00 <jrandom> ah ok, cervantes 18:00 <+fox> <Romster> do jeito difícil, por exemplos e manual :) 18:00 <jrandom> é, sou preguiçoso, eu só uso polecat.i2p/i2psurvey/ e orion.i2p/ :) 18:01 <jrandom> (não preciso fazer spider) 18:01 <+legion> se alguém quiser trabalhar comigo nisso, eu realmente gostaria de corrigir o código e fazê-lo funcionar com python 2.3 ou 2.4 18:01 <+fox> <Romster> tenho 2.4 instalado aqui 18:01 <+Ragnarok> Posso dar uma olhada. Tem link? 18:01 <+fox> <Romster> na verdade acho que é 2.4.1 18:02 <+legion> no momento não tem compatibilidade com py2exe e metade funciona com cada versão, o que significa que quem for rodar precisa ter ambas instaladas. 18:02 * jnymo_ adoraria ver um híbrido orion.i2p/I2PDirectory... informações, categorias, estatísticas... uma beleza 18:02 <+legion> Vou arquivar depois da reunião e postar um link no fórum 18:03 <+Ragnarok> ok 18:03 <jrandom> legion: hmm, você vê muita gente precisando rodar isso? Digo, só algumas pessoas precisam fazer spider 18:03 <+fox> <Romster> ambas, eca, pode ser demais para eu traduzir para a mais nova, não sei até olhar o código 18:03 <jrandom> (não que haja algo errado em facilitar para essas poucas pessoas :) 18:04 <+fox> <Romster> poderia ser dissecado e usado para outras coisas também? 18:04 <+legion> Bem, vejo onde poderia haver alguns usos para todo mundo que roda i2p. 18:04 <+fox> <Romster> poderia* 18:04 <jrandom> hmm, não tenho tanta certeza, pode explicar como? 18:04 <jrandom> digo, não quero todo mundo essencialmente dando DDoS em cada eepsite 18:05 <+legion> Um deles seria uma página de favoritos dinâmica, gerada automaticamente a cada 12-24 horas. 18:05 <jrandom> ah, isso é trivial no syndie (na verdade, um dos recursos principais — 'new blogs') 18:05 <jrandom> ((mas claro, o syndie ainda não tem uma ótima UI para isso)) 18:06 <+fox> <Romster> na verdade só precisaria de alguns para fazer spider e jogar em um banco de dados tipo torrent/DHT e sincronizar isso entre os nós 18:06 <jrandom> isso mesmo, Romster (embora esse banco de dados tipo torrent/DHT para sincronizar, ou "sindi"car, poderia ser o syndie ;) 18:06 <+fox> <Romster> poderia até ser uma forma oculta de descobrir mais nós e serviços i2p 18:06 <+fox> <Romster> sim, ou syndie 18:07 <jrandom> ok, mais alguém tem algo para a reunião? o curry está esfriando ;) 18:08 <+fox> <Romster> se o syndie for tão bom assim, dá para armazenar páginas estáticas em cache e o mesmo com imagens 18:08 <+fox> <reliver> bon appetit, jrandom :-) 18:08 <jrandom> exatamente, romster, dá para fazer isso agora 18:09 <jrandom> ok, se não houver mais nada... 18:09 * jrandom se apronta 18:09 * jrandom *baf* encerra a reunião