Resumo rápido
Presentes: co, jrand0m, LeerokLacerta, mihi, mrflibble, mrsc, nop, shardy, thecrypto, w0rmus
Registro da reunião
[22:53] 0) bem-vindos [22:54] 1) aplicativos: [22:54] 1.1) IM (mensagens instantâneas) [22:54] 1.2) NS (serviço de nomes) [22:54] 2) status de desenvolvimento: [22:54] 2.1) subsistemas [22:54] 2.2) persistência de chave de criptografia [22:54] 2.3) a fazer [22:54] 3) coisas da especificação [22:54] 3.1) mods [22:54] 4) assuntos administrativos: [22:54] 4.1) cvs anônimo [22:54] 5) ? [22:55] ok, 0) boas-vindas [22:55] bem-vindos à reunião 58 [22:55] só isso [22:55] sim, senhor, a menos que alguém tenha algo a acrescentar? [22:55] * nop percebe que jrand0m é orientado a objetos com sua numeração :) [22:56] 3.1.2.2.4.5.8() ;) [22:56] ei, poderiam ser structs ;) [22:56] haha [22:56] isso é verdade mesmo [22:56] ok, 1.1) IM. thecrypto? [22:56] embora [22:56] 2 tenha herança [22:57] ;) [22:57] heh [22:57] não liguem pra mim [22:57] ok [22:57] foi mal [22:57] continuem [22:57] *** mihi_ (~none@anon.iip) entrou no canal #iip-dev [22:57] ok, agora estou enviando algumas especificações básicas para IM [22:58] (Link: http://www.thecrypto.org/i2pim.sxw)http://www.thecrypto.org/i2pim.sxw para o oowriter [22:58] e estou trabalhando no upload do pdf [22:59] se quiser posso colocar no site do i2p [22:59] me dá um segundo [22:59] claro [22:59] *** mrflibble (mrflibble@anon.iip) entrou no canal #iip-dev [22:59] quer colocar isso em i2p/apps/IM/doc/ ? [22:59] *** mihi_ agora é conhecido como mihi_backup [23:00] posso [23:00] sim [23:00] quis dizer no cvs :) [23:00] eu posso fazer isso também [23:00] (mas na web também é bom) [23:00] ah [23:00] haha [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" erro do AR [23:01] tenta de novo [23:01] * jrand0m carregou de boa [23:01] MrEcho: O arquivo PDF? [23:01] (o sxw) [23:01] naquela hora tinha subido só parcialmente [23:01] agora funciona [23:01] hehe [23:02] basicamente eu só coloquei as coisas de presença, mensagens online/offline e uma mensagem de mensagem [23:02] eu descaradamente arranquei algumas seções do documento do I2NP [23:02] :) [23:02] heh achei que algo parecia familiar :) [23:02] também estou subindo a UI que [23:02] tenho trabalhado [23:03] jrand0m: preciso criar os dirs apps/IM/doc [23:03] sim, e dar cvs add neles individualmente [23:03] -kb? [23:03] sim [23:03] thecrypto: Acho que apps/ já está lá agora. [23:04] o que é uma presença? [23:05] deixa eu rodar update [23:05] mas tá entrando [23:05] *** Desconectou: shardy (Ping timeout) [23:05] estou dizendo para destrinchar as especificações [23:05] e a UI vai estar lá em breve também [23:05] e se tiver algo que precise ser esclarecido então anonymail, e-mail, qualquer coisa pra mim e eu corrijo [23:05] perdi a reunião? [23:05] *** shardy (~shardy@anon.iip) entrou no canal #iip-dev [23:05] thecrypto: Você talvez queira anunciar isso na lista de e-mail também, com um link para os documentos. [23:05] pensei que eu tinha colocado isso lá? [23:05] não, ainda estamos no primeiro item, mrflibble [23:05] mrflibble: A reunião está em andamento. [23:05] ah foi mal, só não via o "logger" [23:06] thecrypto> você diz que é um destination, mas é o destination para o qual enviar mensagens? como funcionam as mensagens offline? [23:06] no mids here, so no logger ;) [23:06] ok [23:06] * mrflibble volta a ficar só espreitando [23:06] ah espera, são apenas notificações de presença, foi mal [23:06] como alguém pode assinar uma presença? [23:06] jrand0m: sem mensagens offline [23:07] basicamente [23:07] a presença só encapsula um destination e um nome juntos [23:07] para facilitar [23:08] então se quisermos passar para NS podemos fazer isso, e voltamos a isto depois? [23:09] beleza [23:09] e você ainda pode me mandar perguntas [23:09] na verdade, uma pergunta rápida [23:09] manda ver [23:09] então o IM é estritamente só texto? [23:10] com este básico sim, mas vou adicionar suporte a arquivo [23:10] legal [23:10] só quero cuidar do começo do sistema e construir em cima [23:10] (iterativo e incremental)++ [23:11] ok, ótimo. Vou analisar isso mais a fundo e outras pessoas deveriam também... por enquanto, passando para 1.2) NS. co? [23:11] A versão 1.1 (final) da especificação do serviço de nomes foi lançada mais cedo hoje. [23:12] (e houve grande regozijo) [23:12] Basicamente, terminei as seções sobre as estruturas de dados e mensagens de rede que o programa precisa. [23:12] Vou lançar a API do cliente na quinta-feira. [23:12] E vou começar a implementar o aplicativo NS. [23:12] ótimo [23:13] Uma ideia que mudou é o que a CA (autoridade certificadora) faz quando entidades se registram nela. [23:13] co: como você vai implementar? [23:13] co: o servidor de nomes ou o cliente? [23:14] thecrypto: Bem, primeiro vou implementar as estruturas de dados necessárias. [23:14] Depois, o cliente, depois os componentes de servidor e CA. [23:14] ok [23:15] Como eu dizia, agora eu gostaria que a CA emitisse um certificado para entidades recém-registradas. [23:15] Elas apresentarão esse certificado aos servidores de nomes ao modificar seus registros. [23:15] Não especifiquei o que o certificado contém nesta versão; isso entrará na próxima versão da especificação. [23:16] Alguém acha isso uma má ideia? [23:16] hmm. não seria mais simples/seguro o cliente usar uma chave pública/privada? [23:16] tipo, durante o registro, fornecer uma chave pública para atualizações e assinar o registro, e sempre que quiser atualizar de novo, assinar uma atualização [23:16] (assim a CA nunca obtém a chave privada) [23:17] Observação: todo o material do I2PIM agora foi commitado no repositório cvs [23:17] ótimo [23:17] Pode ser mais simples fazer exatamente isso. Vou repensar essa questão. Obrigado pelo comentário. [23:17] Isso é tudo que tenho para discutir sobre o serviço de nomes neste momento, se você não tiver outras perguntas. [23:18] está bom, ainda não li a 1.1 mas vou enviar e-mail se eu encontrar algo [23:19] OK. Próximo tópico? [23:19] ok, 2.1) status de desenvolvimento dos subsistemas. [23:19] *** w0rmus (o0o@anon.iip) entrou no canal #iip-dev [23:20] o subsistema de transporte está bom o suficiente para avançar. o subsistema de gerenciamento de pares está esboçado com algoritmos toscos, mas funcional. net db, gerenciamento de túnel e gerenciamento de estatísticas ainda pendentes. o subsistema de cliente será trivial (apenas reutilizando o SDK local-only router) [23:21] O que você quer dizer com algoritmos toscos? [23:21] não rápidos? [23:21] é, o subsistema de gerenciamento de pares não está acompanhando o desempenho dos pares, só retorna pares aleatórios. [23:22] o algoritmo será atualizado e ajustado conforme as coisas progredirem para fornecer seleção de pares de forma mais adequada [23:22] a tarefa atual na minha mesa é construir e lidar com garlic messages, o que é um PITA. [23:23] mas viável, só irritante [23:23] isso na verdade leva a 2.2) persistência de chave de criptografia. [23:24] garlic messages usam criptografia ElG+AES para encapsular as camadas dos cloves (gomos) [23:24] e chaves privadas são usadas em outros lugares (transporte, gerenciamento de cliente) [23:25] *** Desconectou: thecrypto (Ping timeout) [23:25] manter chaves privadas e de sessão sempre na memória e nunca em disco é o ideal, mas é ruim quando o router cai (intencionalmente ou por falha) [23:26] alguém tem alguma ideia se devemos 1) nunca escrever as chaves em disco e arriscar perda excessiva e desnecessária de mensagens (já que não serão descriptografáveis) 2) criptografá-las antes de escrever no disco ou 3) simplesmente gravá-las em disco em claro? [23:26] Opção 2. [23:27] jrand0m opção 2, ou fazer o que dissemos antes [23:27] temos que confiar no localhost [23:27] *** Desconectou: cohesion (class) [23:27] assumimos que o localhost não está comprometido [23:27] a coisa estranha da opção 2 é que ou o usuário terá que digitar uma frase secreta para iniciar o router, ou a chave de sessão será conhecida [23:27] bom ponto, nop. [23:28] de novo, somos um transporte, não podemos nos preocupar tanto com isso, isso pode ser modificado no lado do cliente, ou poderíamos dar opções [23:28] dependendo do nível de paranoia [23:28] medida de segurança vs conveniência [23:29] Então proponho ter 3 por padrão e dar ao usuário a opção de usar 2. [23:29] exatamente [23:29] certo. ok, o bom é que as pessoas podem (e devem!) pegar o código do router e modificá-lo para esse tradeoff - um "I2P router chapéu de alumínio" e um "I2P router para usuário comum" [23:29] ok, legal, vou ficar com a simples 3) por enquanto então [23:30] ok 2.3) a fazer [23:30] * co gostaria de revisitar o tópico NS no final da reunião. [23:30] * nop precisa terminar de ler o e-mail do NS [23:30] beleza, você é o item #5 agora [23:30] Posso esperar até o fim. [23:31] mihi montou alguns testes para apontar alguns bugs na implementação do SDK. alguns já corrigidos, outros não. corrigi-los está na lista de afazeres :) [23:32] além disso, houve cerca de uma dúzia de mudanças em várias especificações. assim que eu tiver tempo vou atualizar os docs e publicá-los, embora eu possa apenas colocar uma página de errata no wiki enquanto isso [23:33] word [23:34] outros a fazer... hum, corrigi a coisa de "Wrong Size generating key" esta manhã, além de alguns bugs aleatórios [23:34] ok, é isso para status de dev. 3) coisas da especificação [23:35] 3.1) ver a fazer sobre mods. houve principalmente mudanças tipográficas, me deparei com uma um pouco maior hoje ao implementar os garlics. ainda sem problema, só requer mover algumas estruturas de dados e fazer alguns malabarismos com a criptografia. Colocarei isso na errata. [23:35] 3.2) [eu sei, isso não estava na agenda, mas aqui vai mesmo assim] perguntas da especificação [23:35] (já volto, ainda estou espreitando se precisarem de mim) [23:35] alguém tem alguma pergunta sobre alguma das especificações? [23:35] legal, shardy [23:36] jrand0m: Por favor, diga de novo qual especificação está em qual documento. [23:37] (Link: http://wiki.invisiblenet.net/iip-wiki?I2PProtocolSpecs)http://wiki.invisiblenet.net/iip-wiki?I2PProtocolSpecs tem o mapeamento [23:37] Vou dar uma olhada. [23:38] (olhando isso me lembra que preciso documentar o transporte UDP confiável e seguro. mais um a fazer...) [23:39] houve algumas perguntas de várias pessoas sobre quais especificações olhar - basicamente, a menos que você queira saber como os routers funcionam (ou queira ajudar a implementá-los), você não precisa ler a especificação do I2NP. I2CP e a seção de estruturas de dados do I2CP são suficientes [23:40] jrand0m [23:40] sim, senhor? [23:41] você quer dizer UDP real como em pacotes UDP [23:41] ou UDP como em um protocolo UDP genérico [23:41] sim, UDP como em pacotes UDP [23:41] para I2P [23:41] *** thecrypt1 (~thecrypto@anon.iip) entrou no canal #iip-dev [23:41] *** thecrypt1 agora é conhecido como thecrypto [23:41] i2p/code/router/java/src/net/invisiblenet/i2p/router/transport/udp para a implementação [23:42] voltei [23:42] bem-vindo de volta [23:42] alguém quer me dizer o que aconteceu enquanto eu estava fora? [23:43] a implementação UDP é bem simples - faz uma troca DH (Diffie-Hellman) e as mensagens são divididas em pacotes de 1K e criptografadas com AES256 usando a chave gerada [23:43] rekeying é suportado, embora não automático no momento [23:43] ACKs são enviados de volta em lotes (tipo "Recebi todos os pacotes da mensagem 42 até o pacote 18, mas não 3 ou 7") [23:44] (e a razão prática de eu ter feito a implementação UDP antes da TCP é que o UDP dá E/S assíncrona "de graça" com quase zero overhead) [23:45] claro [23:45] faltam duas coisas nessa implementação udp - colocar Station-to-Station (para MITMs) e adicionar um pacote para "puts, esqueci a chave de sessão" [23:45] bom [23:46] depois do transporte UDP o próximo que quero implementar é o polling HTTP - assim teremos suporte tanto para o usuário comum (UDP) quanto para o usuário atrás de firewall / NAT / proxy (polling http) [23:47] ok, então, é, isso precisa ser documentado numa especificação :) [23:48] * jrand0m !dá um tapa em si mesmo por codificar antes de especificar [23:48] codificar antes de especificar me ajuda [23:48] sim, funciona melhor de forma iterativa [23:48] (já que estamos encontrando problemas nas especificações ao implementá-las, etc.) [23:49] ok, isso é 3) especificações. 4) assuntos administrativos [23:49] 4.1) cvs anônimo. thecrypto? :) [23:49] na hora certa [23:49] bem, estou analisando, acho que a 2401 está bloqueada no momento [23:49] você consegue cvs -d :pserver: localmente? [23:49] e pode haver algumas coisas de inetd a fazer também, valeu jrandom [23:50] ah, legal [23:50] deixa eu testar isso, esqueci que dava pra fazer :) [23:51] seria só cvs -d :pserver: ? [23:51] cvs -d :pserver:anonymous@localhost:/home/cvsgroup/cvsroot/ co i2p [23:52] também, seria ótimo se pudéssemos colocar um bugzilla lá também [23:52] acvs [checkout aborted]: connect to localhost(127.0.0.1):2401 failed: Connection refused [23:52] beleza, depois de adicionar a linha do inetd.conf e dar kill -HUP no identd? [23:52] deixa eu tentar essa linha do inet e eu te retorno [23:52] quer dizer, inetd :) [23:52] beleza [23:53] o pserver vai na mesma linha? [23:53] sim, é tudo em uma linha [23:55] ok, isso é tudo nos assuntos administrativos, pelo menos que eu lembre [23:55] 5a) co, é com você [23:56] Quando duas pessoas querem registrar o mesmo nome de entidade, a segunda é recusada. [23:56] Mas se usarmos uma abordagem baseada em assinatura, [23:56] a pessoa que foi recusada poderia enviar uma mensagem ao servidor de nomes [23:56] mesmo assim, dizendo para ele modificar o registro. [23:56] Há duas possibilidades: [23:57] 1) A CA envia ao servidor de nomes uma cópia da chave pública da entidade que foi aprovada. [23:57] 2) A CA envia à pessoa que está registrando um nome um certificado, assinado por sua chave privada. O servidor de nomes terá a chave pública da CA para verificá-lo. [23:58] Se um usuário malicioso disser ao servidor de nomes para modificar um certo registro, a falta de um certificado impediria a modificação. [23:58] Era nisso que eu estava pensando. [23:59] mas nesse caso a CA conhece a chave - cripto assimétrica significaria que a CA só conhece a chave pública, além disso a CA nunca iria querer ou precisar fornecer essa chave pública a ninguém - ela serve apenas para o atualizador legítimo assinar quando solicitar uma atualização [00:00] o que você está descrevendo parece mais cripto simétrica - usar uma senha, essencialmente [00:00] o cvs está me sacaneando! [00:00] (onde o certificado é o segredo compartilhado entre CAs e o proprietário legítimo do pseudônimo (nym)) [00:00] *** mrsc (~efgsdf@anon.iip) entrou no canal #iip-dev [00:01] o que houve, thecrypto? [00:01] adicionei o usuário anonymous com senha em branco, coloquei em readers e no cvsgroup e recebo cvs login: authorization failed: server localhost rejected access to /home/cvsgroup/cvsroot for user anonymous [00:01] jrand0m: Bom ponto. Digamos que esta parte da especificação não está finalizada, e vou pensar mais sobre isso. [00:01] beleza [00:01] *** LeerokLacerta (~leerok@anon.iip) entrou no canal #iip-dev [00:02] Konnichiwa. [00:02] hmm thecrypto, acho que você não quer um usuário anônimo do SO [00:02] oi, LeerokLacerta [00:02] Olá, jrand0m. [00:02] bem, coloquei uma senha e agora funciona [00:03] jrand0m: E se você tiver mais sugestões depois de ler a spec, me envie. [00:03] farei isso, co [00:03] legal, thecrypto.. /bin/false é o shell deles? [00:03] agora só tenho que achar aquela seção no manual do cvs sobre como criar um usuário [00:03] -> *thecrypto* qual é a senha? [00:04] agora é [00:05] ok, podemos resolver isso depois da reunião. [00:05] ok, último ponto da agenda: 5b) ? [00:05] alguma pergunta / ideia / preocupação? [00:05] só confiram o app IM [00:06] por enquanto tudo que ele faz é montar uma árvore, mas mostra como está começando a ficar [00:06] Sem SOCKS? [00:06] ahh é isso que eu esqueci [00:06] ah legal, thecrypto [00:06] SOCKS? tipo, o protocolo de proxy? [00:06] alguém aqui é bom em fazer ícones? [00:06] Sim. [00:06] A resposta todas as vezes que perguntei foi "Não". [00:07] ah. sim, definitivamente vamos querer um proxy SOCKS, mas ninguém está trabalhando nisso no momento. [00:07] Hmm. [00:07] isso vai ser um dos apps que vamos querer até a 1.0 pública, para que as pessoas possam navegar sites baseados em i2p, e também para que as pessoas possam navegar na web normal anonimamente [00:07] há proxies socks suficientes disponíveis de graça, eu diria ;) [00:08]