Reunião de Desenvolvimento do I2P - 22 de abril de 2014

20:32:31 <str4d> Olá a todos 20:34:53 <str4d> 0) Oi 20:34:53 <str4d> 1) TODO 0.9.13-0.9.16 http://zzz.i2p/topics/1600 20:34:53 <str4d> 2) Novo transporte para os PTs do Tor http://zzz.i2p/topics/1551 20:34:53 <str4d> 3) Quaisquer itens que surgirem de 1) 20:34:53 <str4d> Atividade pós-reunião: teste de estresse do Mumble (bate-papo por voz sobre I2P) 20:35:07 <iRelay> Título: zzz.i2p: TODO 0.9.13 - 0.9.16 (em zzz.i2p) 20:35:10 <iRelay> Título: zzz.i2p: Suporte aos Pluggable Transports do Tor (em zzz.i2p) 20:35:29 <str4d> 0) Oi 20:35:57 <hottuna> Olá 20:37:37 <str4d> Mais alguém? 20:38:01 <str4d> zzz2 orion psi kytv meeh_ 20:41:17 <str4d> Com sorte, alguns deles vão aparecer. 20:41:17 <str4d> 1) TODO 0.9.13-0.9.16 http://zzz.i2p/topics/1600 20:41:22 <iRelay> Título: zzz.i2p: TODO 0.9.13 - 0.9.16 (em zzz.i2p) 20:41:26 <zzz2> aqui 20:41:58 <str4d> A pedido do zzz, iniciámos um tópico de discussão para propor ideias para o roteiro (roadmap) do I2P daqui para frente. 20:42:27 <str4d> Houve muita conversa, mas não se chegou a um consenso. 20:43:14 <str4d> Resumi algumas das sugestões iniciais na página do roadmap http://trac.i2p2.i2p/wiki/Roadmaps/1.0 20:43:17 <iRelay> Título: Roadmaps/1.0 I2P Bugtracker (em trac.i2p2.i2p) 20:45:01 <str4d> zzz2: Vejo que você tem se dedicando ao susimail (oba) 20:46:19 <zzz2> é, caí nesse buraco de coelho enquanto tentamos decidir o que é realmente importante 20:52:07 <str4d> Acho que foi um trabalho útil, nem que seja porque há um bug antigo sobre problemas de login, e o susimail é um dos primeiros apps que os usuários vão experimentar 20:52:08 <str4d> http://trac.i2p2.i2p/ticket/747 20:52:12 <iRelay> Título: #747 (Problemas de login com o Susimail) I2P Bugtracker (em trac.i2p2.i2p) 20:54:45 <psi> str4d: ohai 20:54:47 * psi está atrasado? 20:55:19 <str4d> sim, psi está 20:55:25 <str4d> Ainda não aconteceu muita coisa :/ 20:55:58 * psi rola a tela para cima 20:56:07 <str4d> Para resumir o que vem acontecendo desde que o RFC foi publicado: 20:56:18 <str4d> - zzz tem trabalhado no susimail 20:56:59 <str4d> - psi tem se familiarizado com PTs, novo DH e JNI 20:57:23 <str4d> - Eu tenho trabalhado no I2P-Bote Android e, agora, em Java EdDSA 20:57:39 * psi passou o dia inteiro detalhando a estrutura de PT para i2p 20:58:59 <zzz2> se str4d e psi estão progredindo em EdDSA, 25519 e PTs, então acho que o melhor uso do meu tempo é avançar na migração para o novo algoritmo de assinatura, p.ex., múltiplos dests por um tunnel, e algum tipo de suporte a addressbook 21:00:27 <jenkins@kyirc> Iniciando build #581 para o job I2P 21:01:01 <zzz2> qual é o status das chaves mtn do psi e do acordo de desenvolvimento? Não recebi nada pelo correio. 21:01:23 <str4d> psi assinou o acordo de desenvolvimento, eu publiquei no site 21:01:36 <str4d> (então as chaves públicas dele estão registradas) 21:02:10 <zzz2> a impressão digital da chave dele está lá também? 21:02:32 <zzz2> se sim vou adicioná-lo e anunciar 21:03:02 <psi> minha fp do gpg está no meu twitter 21:03:05 <str4d> não a impressão digital, mas a própria chave está 21:03:47 <zzz2> isso precisa estar naquele arquivo de template de exemplo monotonerc. psi, talvez você possa fazer isso como seu primeiro teste de habilidades com mtn? 21:04:23 <jenkins@kyirc> Iupiii, build corrigido! 21:04:24 <jenkins@kyirc> Projeto I2P build #581: CORRIGIDA em 3 min 55 s: http://jenkins.killyourtv.i2p/job/I2P/581/ 21:04:36 <psi> posso fazer isso 21:04:40 <psi> já fiz isso localmente 21:04:53 <str4d> zzz2, psi, atualizei o Gantt do roadmap - http://trac.i2p2.i2p/wiki/Roadmaps/1.0 21:04:56 <iRelay> Título: Roadmaps/1.0 I2P Bugtracker (em trac.i2p2.i2p) 21:05:21 <psi> a fp da chave monotone para minha chave de transporte NOT é "1ceb85b992114bae1bcb156ef238f8f3044a6bfe", -- ampernand@gmail.com 21:06:04 <psi> posso pegar a fp da minha chave de transporte também 21:06:29 <zzz2> ok, ótimo, bem-vindo ao time! Como digo a todos, por favor, tenha cuidado, pratique no www primeiro 21:06:30 <str4d> psi: você precisa enviar isso para o eche, kytv e welt 21:06:43 <str4d> +1 21:06:56 * kytv recebeu e está adicionando no servidor dele 21:07:08 <zzz2> psi, temos instruções bem precisas na página da web sobre como fazer tudo isso... :) 21:07:27 <psi> vou revisar isso 21:07:38 <zzz2> p.ex., me enviar e-mail (mas para você não é mais necessário) 21:08:15 <str4d> Como está o Gantt do roadmap para todos agora? Há itens que parecem irrealistas, ou algo faltando 21:08:16 <str4d> ? 21:09:37 * psi revisa o roadmap 21:09:43 <jenkins@kyirc> Projeto I2P UnitTests build #528: SUCESSO em 5 min 6 s: http://jenkins.killyourtv.i2p/job/UnitTests/528/ 21:09:57 <jenkins@kyirc> Iniciando build #82 para o job I2P-Android 21:09:59 <str4d> zzz2: sugiro que você resolva o item das novas chaves GPG mais cedo do que tarde ;) 21:10:19 <zzz2> str4d, por favor nos diga o que isso está te dizendo sobre o que é importante 21:10:33 <str4d> psi: você está encontrando muita sobreposição entre seu trabalho com PTs e NTCP2? 21:10:34 <zzz2> sim, vou fazer isso antes do próximo lançamento, prometo 21:11:24 <str4d> Na minha opinião (IMHO), há três coisas importantes: 21:11:32 <jenkins@kyirc> Projeto I2P-Android build #82: SUCESSO em 1 min 34 s: http://jenkins.killyourtv.i2p/job/I2P-Android/82/ 21:11:40 <str4d> 1) progresso na atualização de criptografia - agora finalmente em andamento 21:12:01 <psi> str4d: no momento, ainda não olhei o ntcp2 21:12:13 <str4d> (dando sequência ao trabalho de preparação) 21:13:28 <zzz2> 1) "agora em andamento"? Tenho ralado muito nisso há 6 meses 21:13:32 <str4d> 2) Preparação para auditoria - na minha opinião, precisamos colocar nosso modelo de ameaça etc. em dia o quanto antes (ASAP) 21:15:33 * psi fica afk por 30 minutos 21:15:33 <psi> evento inesperado, bbl 21:15:33 <psi> vou olhar o scrollback depois 21:16:21 <zzz2> Parece haver alguma confusão por aí sobre a "nova criptografia de assinatura". Está pronta, está disponível na 0.9.12, funciona. Para destinations. 21:17:06 <zzz2> A "única" coisa não feita é migrar destinations publicados existentes para um novo. 21:21:13 <str4d> sim, o que primeiro depende de escolher um novo, que na minha opinião deve ser Ed25519, o que depende de obter uma implementação rápida. 21:21:15 <str4d> E, ao mesmo tempo, concordo que a infraestrutura de migração restante necessária deve ser implementada. 21:21:16 <str4d> <str4d> Por anos deixamos isso de lado e trabalhamos no que achamos benéfico para os usuários, mas, na minha opinião, se quisermos começar a atrair mais interesse de pesquisa e utilizá-lo de forma eficaz, precisamos estar mais conscientes do que o I2P pode e não pode alcançar. 21:21:17 <str4d> <str4d> Eu sei que você tem, zzz ;P 21:21:18 <str4d> <str4d> (Eu estava me referindo especificamente à parte que envolve a nova criptografia em si) 21:21:19 <str4d> <str4d> obrigado pelo esforço que você colocou para chegar até aqui :) 21:21:20 <str4d> <str4d> 3) Usabilidade, UX - este é um terceiro ponto importante que não está no gráfico do Roadmap 21:21:22 <str4d> <str4d> Bem - o trabalho do zzz no susimail entra nessa categoria, assim como melhorias no streaming 21:21:41 <str4d> <str4d> Mas também é importante revisar nossas páginas de erro e de ajuda, e como auxiliamos o usuário a realizar suas tarefas. 21:21:41 <str4d> (depois da minha linha "2) Preparação para auditoria") 21:22:00 <str4d> Preciso ficar AFK em 10-15 min 21:22:50 <str4d> E como o psi está AFK, vou retirar "2) Novo transporte para os PTs do Tor" desta reunião 21:23:55 <str4d> zzz2: na sua opinião, o que precisamos fazer antes de organizar uma reunião com o Lance sobre o modelo de ameaça? 21:24:59 * str4d gostaria de tentar uma reunião com o Lance em maio 21:26:04 <str4d> então precisamos definir o que devemos fazer antes disso, para podermos organizar a reunião com tempo suficiente para terminar isso primeiro. 21:29:27 <zzz2> Discordo que primeiro precisamos escolher. 21:29:59 <zzz2> Ou, que possamos escolher agora (P256) e escolher de novo mais tarde quando houver mais opções disponíveis. 21:30:02 <MTN@kyirc> [ I2P ] correção de compilação [zzz@mail.i2p] http://killyourtv.i2p/viewmtn/revision/info/12396c3ee88d1194482fc2cc3751db1169cc52e3 21:30:34 <zzz2> Poderíamos mudar o padrão para novos dests para P256 na 0.9.13, se quisermos. 21:30:35 <str4d> zzz2: se chegarmos ao ponto em que o sistema de nomes consiga lidar com escolhas dinâmicas de enc, então eu concordo 21:31:05 <zzz2> P256 é claramente melhor que DSA 21:31:34 <str4d> Também concordo. 21:31:43 <zzz2> Acho melhor os haters do P256 darem um passo atrás e pensarem em quão ruim é o DSA 1024. 21:32:03 <MTN@kyirc> [ WWW ] adicionando a chave de transporte do psi [kytv@mail.i2p] http://killyourtv.i2p/viewmtn/revision/info/029163d2d446f10ab1a129b559802fabac2ef8b7 21:32:52 <str4d> zzz2: entendo seu ponto. 21:33:39 <zzz2> sobre: auditoria e Lance, sempre é uma boa hora. você tem alguma atualização do processo de auditoria para nós, vinda da lista de e-mails? 21:33:40 <str4d> Parte do motivo de eu querer ter EdDSA funcionando antes da troca é que, com base no que você disse em tópicos antes, eu não gostaria de trocar o algoritmo de assinatura de Dest duas vezes. 21:34:14 <str4d> sim, da segunda vez seria um pouco mais fácil porque o suporte a multi dest etc. já estaria lá, mas a parte de nomes ainda é o ponto fraco. 21:34:48 <zzz2> para servidores você não quer mudar duas vezes, mas para clientes não importa 21:35:04 <str4d> bem observado. 21:35:23 <str4d> Há algo que impediria Dests novos de falar com os antigos? 21:35:31 <nombre_> então, pelo que entendi, vocês estão fazendo upgrades de criptografia? existe talvez uma página que detalhe tudo o que estão planejando? e, sobre uma implementação de 25519, vocês poderiam simplesmente usar NaCl via JNI, ou Kalium, embora isso possa ser um tanto limitante 21:35:34 <zzz2> e mesmo para servidores, se você mudar para P256 dificilmente vale a pena mudar de novo, a menos que saia alguma notícia muito ruim sobre P256 21:35:54 <str4d> Se não, pode ser uma boa ideia colocar os clientes em P256 antes 21:36:08 <zzz2> novos dests podem falar com os antigos e vice-versa, desde que ambos estejam na 0.9.12 ou posterior 21:36:39 <str4d> zzz2: http://blog.cr.yp.to/20140323-ecdsa.html é razão suficiente para eu não querer permanecer em ECDSA 21:36:43 <iRelay> Título: cr.yp.to: 2014.03.23: How to design an elliptic-curve signature system (em blog.cr.yp.to) 21:37:56 <str4d> não por um único ponto (ainda), mas se conseguirmos uma implementação de EdDSA eficaz e *correta*, acho que seria muito benéfico mudar 21:38:27 <str4d> nombre_: http://trac.i2p2.i2p/ticket/856 21:38:30 <iRelay> Título: #856 (Revisão/migração de criptografia) I2P Bugtracker (em trac.i2p2.i2p) 21:38:30 <str4d> (e links ali dentro) 21:38:40 <nombre_> obrigado str4d 21:38:53 <zzz2> nada ali me diz para adiar se livrar do DSA. Também não há nada ali que me faça entrar em pânico sobre P256. Há algo melhor que P256? claro. 21:39:15 <str4d> sem atualizações reais, propriamente ditas, da lista de e-mails da OpenITP; não tem havido muita atividade real ultimamente. 21:40:38 <zzz2> Eu reservei espaço para 65536 algoritmos de assinatura e implementei 7. Faltam 65529, podemos adicionar alguns a cada release se quisermos. 21:43:27 <str4d> zzz, eu apoiaria mover os clientes para p256 na 0.9.13 21:44:47 <str4d> mas se a transição de servidor ainda não for ser tranquila, eu preferiria esperar um pouco e ver como vai o trabalho em EdDSA. 21:45:49 <nombre_> eu também (não que minha opinião valha algo), o ECDSA da NIST é melhor que DSA, mesmo que alguns de nós, paranoicos de chapéu de alumínio, só se sintam seguros quando for 25519 21:46:48 <nombre_> quebrar dest/b32 é meio que esperado, né? 21:47:13 <str4d> levou muito tempo e muito trabalho para chegar a este ponto, não faz sentido correr na última hora 21:49:48 * RN dá uma espiada e olha em volta 21:54:36 <zzz2> há 1) clientes 2) novos servidores e 3) migração de servidores existentes. 21:54:43 <zzz2> 1 e 2 podemos fazer agora, 3) dá muito mais trabalho. 21:54:59 <zzz2> 1 e 2 quebram a compatibilidade com routers antigos, i2pcpp e i2pd, até que eles alcancem 21:55:16 <nombre_> então há alguém trabalhando em achar/criar uma implementação em Java de 25519? e qual é o prazo estimado de quando ela seria utilizável? 21:55:28 <nombre_> presumo que com p256 isso já seja viável porque isso está incluído no Bouncy Castle? 21:55:52 <zzz2> p256 está na JVM 21:56:06 <nombre_> ah, melhor ainda 21:56:17 <zzz2> temos 25519 em Java agora, mas é lento demais para ser utilizável. str4d e psi estão tentando acelerar 21:57:39 <nombre_> hmm, bem, sem saber nada de cripto, eu acharia que usar JNI seria a maneira mais simples de acelerar. talvez eu deva estudar mais o 25519 para entender quais partes são os gargalos 23:02:36 <str4d> Ninguém realmente encerrou quando eu fui afk, então: 23:02:53 * str4d *baf* encerra a reunião.