Récapitulatif rapide
Présents : co, jrand0m, LeerokLacerta, mihi, mrflibble, mrsc, nop, shardy, thecrypto, w0rmus
Journal des réunions
[22:53] 0) bienvenue [22:54] 1) apps: [22:54] 1.1) IM [22:54] 1.2) NS [22:54] 2) statut dev: [22:54] 2.1) sous-systèmes [22:54] 2.2) persistance des clés de chiffrement [22:54] 2.3) à faire [22:54] 3) trucs de spec [22:54] 3.1) mods [22:54] 4) administrivia: [22:54] 4.1) anon cvs [22:54] 5) ? [22:55] ok, 0) bienvenue [22:55] bienvenue à la réunion 58 [22:55] c'est tout [22:55] si sr, à moins que quelqu'un ait quelque chose à ajouter ? [22:55] * nop remarque que jrand0m est orienté objet avec sa numérotation :) [22:56] 3.1.2.2.4.5.8() ;) [22:56] hé, ça pourrait être des structs ;) [22:56] haha [22:56] c'est tout à fait vrai [22:56] ok, 1.1) IM. thecrypto ? [22:56] quoique [22:56] 2 a de l'héritage [22:57] ;) [22:57] heh [22:57] ne faites pas attention à moi [22:57] ok [22:57] désolé [22:57] continuez [22:57] *** mihi_ (~none@anon.iip) a rejoint le canal #iip-dev [22:57] ok, là tout de suite je téléverse quelques specs de base pour l'IM [22:58] (Link: http://www.thecrypto.org/i2pim.sxw)http://www.thecrypto.org/i2pim.sxw pour oowriter [22:58] et je suis en train de téléverser le PDF [22:59] si tu veux je peux le mettre sur le site i2p [22:59] une seconde [22:59] d'accord [22:59] *** mrflibble (mrflibble@anon.iip) a rejoint le canal #iip-dev [22:59] veux-tu mettre ça dans i2p/apps/IM/doc/ ? [22:59] *** mihi_ se nomme désormais mihi_backup [23:00] Je peux [23:00] oui [23:00] je voulais dire dans cvs :) [23:00] je peux le faire aussi [23:00] (mais sur le web c'est bien aussi) [23:00] oh [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" Erreur AR [23:01] réessaie [23:01] * jrand0m l'a chargé sans problème [23:01] MrEcho: Le fichier PDF ? [23:01] (le sxw) [23:01] n'était qu'en partie téléversé à ce moment-là [23:01] maintenant ça marche [23:01] héhé [23:02] en gros j'ai seulement mis la partie présence, les messages en ligne/hors ligne, et un message "message" [23:02] j'ai honteusement pompé quelques sections du document I2NP [23:02] :) [23:02] heh je me disais bien que ça me disait quelque chose :) [23:02] je suis aussi en train de téléverser l'UI que j [23:02] sur laquelle je travaille [23:03] jrand0m: dois-je créer les répertoires apps/IM/doc [23:03] oui, et faire un cvs add dessus individuellement [23:03] -kb? [23:03] oui [23:03] thecrypto: Je crois que apps/ y est maintenant. [23:04] c'est quoi une présence ? [23:05] laisse-moi faire un update [23:05] mais c'est en train d'arriver là-dedans [23:05] *** Déconnexion: shardy (Ping timeout) [23:05] je dis juste de démonter les specs [23:05] et l'UI y sera bientôt aussi [23:05] et si vous avez quoi que ce soit à clarifier, anonymail, e-mail, peu importe, envoyez-moi et je corrigerai [23:05] j'ai raté la réunion ? [23:05] *** shardy (~shardy@anon.iip) a rejoint le canal #iip-dev [23:05] thecrypto: Tu pourrais aussi l'annoncer sur la liste e-mail, avec un lien vers les documents. [23:05] je croyais avoir mis ça ? [23:05] non, on est toujours au premier point mrflibble [23:05] mrflibble: La réunion est en cours. [23:05] oh désolé, je ne voyais juste pas « logger » [23:06] thecrypto> tu dis que c'est une destination, mais est-ce la destination à laquelle envoyer les messages ? comment fonctionnent les messages hors ligne ? [23:06] pas de mids ici, donc pas de logger ;) [23:06] ok [23:06] * mrflibble retourne en lurking [23:06] ah attends, ce ne sont que des notifications de présence, désolé [23:06] comment peut-on s'abonner à une présence ? [23:06] jrand0m: pas de messages hors ligne [23:07] en gros [23:07] la présence encapsule juste une destination et un nom ensemble [23:07] pour simplifier les choses [23:08] donc si on veut passer à NS on peut, et on pourra revenir dessus plus tard ? [23:09] 'k cool [23:09] et vous pouvez toujours m'envoyer des questions [23:09] en fait, une petite question rapide [23:09] vas-y [23:09] donc l'IM c'est strictement du texte uniquement ? [23:10] avec cette base oui, mais j'ajouterai la prise en charge des fichiers [23:10] cool [23:10] je veux juste poser les bases du système et construire dessus [23:10] (itératif et incrémental)++ [23:11] ok super. Je vais regarder ça plus en détail et les autres devraient aussi... pour l'instant, passons à 1.2) NS. co ? [23:11] La version 1.1 (finale) de la spécification du service de noms a été publiée plus tôt aujourd'hui. [23:12] (et ce fut l'allégresse) [23:12] En gros, j'ai terminé les sections sur les structures de données et les messages réseau dont le programme a besoin. [23:12] Je publierai l'API client jeudi. [23:12] Et je commencerai à implémenter l'application NS. [23:12] génial [23:13] Une idée qui a changé concerne ce que fait la CA (autorité de certification) lorsque des entités s'enregistrent auprès d'elle. [23:13] co: comment vas-tu l'implémenter ? [23:13] co: le serveur de noms ou le client ? [23:14] thecrypto: Eh bien, d'abord j'implémenterai les structures de données nécessaires. [23:14] Ensuite le client, puis les composants serveur et CA. [23:14] d'accord [23:15] Comme je le disais, je voudrais maintenant que la CA délivre un certificat aux entités nouvellement enregistrées. [23:15] Elles présenteront ce certificat aux serveurs de noms lors de la modification de leurs enregistrements. [23:15] Je n'ai pas spécifié ce que contient le certificat dans cette version ; cela ira dans la prochaine version de la spécification. [23:16] Est-ce que cela semble une mauvaise idée à quelqu'un ? [23:16] hmm. ne serait-il pas plus simple/sûr de faire utiliser au client une clé publique/clé privée ? [23:16] c.-à-d. lors de l'inscription, fournir une clé publique pour les mises à jour et signer l'enregistrement, et chaque fois que tu veux mettre à jour à nouveau, signer une mise à jour [23:16] (de sorte que la CA n'obtienne jamais la clé privée) [23:17] Aparté : tout le bazar I2PIM est maintenant commit dans le dépôt cvs [23:17] génial [23:17] Ce serait peut-être plus simple de faire juste ça. Je vais repenser cette question. Merci pour le commentaire. [23:17] C'est tout ce que j'ai à discuter pour le service de noms pour le moment, si vous n'avez pas d'autres questions. [23:18] ça a l'air bien, je n'ai pas encore parcouru la 1.1 mais j'enverrai un e-mail si je tombe sur quelque chose [23:19] OK. Sujet suivant ? [23:19] ok, 2.1) statut du dev pour les sous-systèmes. [23:19] *** w0rmus (o0o@anon.iip) a rejoint le canal #iip-dev [23:20] le sous-système de transport est suffisamment bon pour avancer. le sous-système de gestion des pairs est ébauché avec des algorithmes idiots mais fonctionnel. les sous-systèmes base de données réseau, gestion de tunnel, et gestion des stats sont encore en attente. le sous-système client sera trivial (en réutilisant simplement le router local-only du SDK) [23:21] Qu'entends-tu par algorithmes idiots ? [23:21] pas rapides ? [23:21] eh, le sous-système de gestion des pairs ne suit pas les performances des pairs, il renvoie juste des pairs au hasard. [23:22] l'algorithme sera mis à jour et affiné à mesure que les choses progressent pour fournir une meilleure sélection des pairs [23:22] ma tâche actuelle est de construire et gérer les garlic messages, ce qui est un PITA. [23:23] mais faisable, juste pénible [23:23] ça mène justement à 2.2) persistance des clés de chiffrement. [23:24] les garlic messages utilisent du chiffrement ElG+AES pour envelopper les couches des gousses [23:24] et des clés privées sont utilisées ailleurs (transport, gestion du client) [23:25] *** Déconnexion: thecrypto (Ping timeout) [23:25] garder les clés privées et de session toujours en mémoire et jamais sur disque est idéal, mais c'est nul quand le router tombe (intentionnellement ou par erreur) [23:26] des avis sur le fait qu'on devrait 1) ne jamais écrire les clés sur disque et risquer des pertes de messages excessives et inutiles (puisqu'ils ne seraient pas déchiffrables) 2) les chiffrer avant de les écrire sur disque ou 3) simplement les écrire en clair sur disque ? [23:26] Option 2. [23:27] jrand0m option 2, ou faire ce qu'on a dit avant [23:27] on doit faire confiance à localhost [23:27] *** Déconnexion: cohesion (class) [23:27] on suppose que localhost n'est pas compromis [23:27] le truc étrange avec l'option 2, c'est que soit l'utilisateur devra entrer une phrase de passe pour démarrer le router, soit la clé de session sera connaissable [23:27] bon point nop. [23:28] encore une fois, nous sommes un transport, on ne peut pas trop se soucier de ça, ça peut être modifié côté client, ou on pourrait leur donner des options [23:28] selon le niveau de paranoïa [23:28] équilibre sécurité vs commodité [23:29] Alors je propose d'avoir 3 par défaut, et de donner à l'utilisateur l'option d'utiliser 2. [23:29] exactement [23:29] oui. ok, l'avantage c'est que les gens peuvent (et devraient !) prendre le code du router et le modifier selon ce compromis - un « tinfoil I2P router » et un « jane sixpack I2P router » [23:29] ok, cool, je vais me contenter du simple 3) pour l'instant alors [23:30] ok 2.3) à faire [23:30] * co aimerait revenir sur le sujet NS à la fin de la réunion. [23:30] * nop doit finir de lire l'e-mail NS [23:30] 'k, tu es le point n°5 maintenant [23:30] Je peux attendre la fin. [23:31] mihi a monté quelques tests pour mettre en évidence des bugs dans l'impl du SDK. certains sont déjà corrigés, d'autres non. les corriger est sur la todo :) [23:32] également, il y a eu une douzaine de changements dans diverses specs. dès que j'aurai le temps je mettrai à jour la doc et je la pousserai, bien que je puisse simplement mettre une page d'errata sur le wiki en attendant [23:33] word [23:34] autres choses à faire... euh, j'ai corrigé le truc « Wrong Size generating key » ce matin plus quelques bugs aléatoires [23:34] ok, c'est tout pour le statut dev. 3) trucs de spec [23:35] 3.1) voir la todo à propos des mods. il y a surtout eu des changements typographiques, je suis tombé sur un un peu plus gros aujourd'hui en implémentant les garlics. toujours pas de problème, ça nécessite juste de déplacer quelques structures de données et de faire un peu d'acrobatie avec le chiffrement. je mettrai ça dans l'errata. [23:35] 3.2) [je sais, celui-ci n'était pas à l'ordre du jour, mais le voilà quand même] questions sur les specs [23:35] (brb, je suis toujours là en lurking si vous avez besoin de moi) [23:35] quelqu'un a des questions sur une des specs ? [23:35] cool shardy [23:36] jrand0m: Peux-tu nous redire quelle spec est dans quel document. [23:37] (Link: http://wiki.invisiblenet.net/iip-wiki?I2PProtocolSpecs)http://wiki.invisiblenet.net/iip-wiki?I2PProtocolSpecs les répertorie [23:37] Je vais regarder. [23:38] (en regardant ça je me rappelle que je dois documenter le transport UDP sûr et fiable. encore une autre todo...) [23:39] il y a eu des questions de diverses personnes concernant quelles specs regarder - en gros, à moins que vous vouliez savoir comment les routers fonctionnent (ou que vous vouliez aider à les implémenter), vous n'aurez pas besoin de lire la spec I2NP. I2CP et la section I2CP des structures de données suffisent [23:40] jrand0m [23:40] si sr ? [23:41] tu veux dire UDP réel au sens paquets UDP [23:41] ou UDP au sens d'un protocole de type UDP en général [23:41] oui, UDP au sens paquets UDP [23:41] pour I2P [23:41] *** thecrypt1 (~thecrypto@anon.iip) a rejoint le canal #iip-dev [23:41] *** thecrypt1 se nomme désormais thecrypto [23:41] i2p/code/router/java/src/net/invisiblenet/i2p/router/transport/udp pour l'implémentation [23:42] de retour [23:42] wb [23:42] quelqu'un veut bien m'envoyer ce qui s'est passé pendant mon absence ? [23:43] l'impl UDP est assez simple - elle fait un échange DH et les messages sont découpés en paquets de 1K et chiffrés en AES256 avec la clé générée [23:43] le rekeying est pris en charge mais pas automatique pour le moment [23:43] des ACK sont renvoyés par lots (aka « J'ai reçu tous les paquets du message 42 jusqu'au paquet 18 mais pas les 3 ou 7 ») [23:44] (et la raison pratique pour laquelle j'ai fait l'impl UDP avant l'impl TCP, c'est qu'UDP donne des E/S asynchrones « gratuites » avec presque 0 overhead) [23:45] bien sûr [23:45] il reste deux choses à faire dans cette impl udp - faire du Station-to-Station pour les MITM et ajouter un paquet pour « oh merde, j'ai oublié la clé de session » [23:45] bien [23:46] après le transport UDP, le prochain que je veux implémenter est le HTTP par sondage (polling) - ainsi nous aurons le support à la fois pour l'utilisateur lambda (UDP) et pour l'utilisateur derrière un pare-feu / un NAT / un proxy (polling HTTP) [23:47] ok, donc, oui, il faut documenter ça dans une spec :) [23:48] * jrand0m !thwaps self for coding before specing [23:48] coder avant d'écrire la spec m'aide [23:48] oui, ça marche mieux de façon itérative [23:48] (puisqu'on trouve des problèmes dans les specs en les implémentant, etc.) [23:49] ok, c'était 3) specs. 4) administrivia [23:49] 4.1) anon cvs. thecrypto ? :) [23:49] juste à temps [23:49] eh bien, je regarde ça, je pense que 2401 est actuellement bloqué [23:49] peux-tu cvs -d :pserver: en local ? [23:49] et il y a peut-être aussi des trucs inetd à faire merci jrandom [23:50] ah cool' [23:50] laisse-moi tester ça j'avais oublié que tu pouvais faire ça :) [23:51] ce serait juste cvs -d :pserver: ? [23:51] cvs -d :pserver:anonymous@localhost:/home/cvsgroup/cvsroot/ co i2p [23:52] aussi, ce serait génial si on pouvait mettre un bugzilla là-dessus aussi [23:52] acvs [checkout aborted]: connect to localhost(127.0.0.1):2401 failed: Connection refused [23:52] 'k, après avoir ajouté la ligne inetd.conf et fait un kill -HUP identd ? [23:52] laisse-moi essayer cette ligne inet et je te reviens [23:52] euh, inetd :) [23:52] 'k cool [23:53] le pserver va sur la même ligne ? [23:53] oui, tout ça tient sur une seule ligne [23:55] ok, c'est tout pour l'administrivia, du moins à ce à quoi je pense [23:55] 5a) co, à toi [23:56] Quand deux personnes veulent enregistrer le même nom d'entité, la seconde est refusée. [23:56] Mais si nous utilisons une approche basée sur des signatures, [23:56] la personne qui a été refusée pourrait quand même envoyer un message au serveur de noms [23:56] lui disant de modifier l'enregistrement. [23:56] Il y a deux possibilités : [23:57] 1) la CA envoie au serveur de noms une copie de la clé publique de l'entité approuvée. [23:57] 2) la CA envoie à la personne qui enregistre un nom un certificat, signé par sa clé privée. Le serveur de noms aura la clé publique de la CA pour le vérifier. [23:58] Si un utilisateur malveillant dit au serveur de noms de modifier un certain enregistrement, l'absence de certificat empêcherait la modification. [23:58] C'est ce que je pensais. [23:59] mais dans ce cas la CA connaît la clé - la crypto asymétrique voudrait dire que la CA ne connaît jamais que la clé publique, et la CA ne voudrait ni n'aurait besoin de donner cette clé publique à qui que ce soit - elle sert juste au véritable metteur à jour pour signer lorsqu'il demande une mise à jour [00:00] ce que tu décris ressemble plutôt à de la crypto symétrique - utiliser en gros une phrase de passe [00:00] cvs me joue des tours ! [00:00] (où le certificat est le secret partagé entre les CA et le propriétaire authentique du nym (pseudonyme)) [00:00] *** mrsc (~efgsdf@anon.iip) a rejoint le canal #iip-dev [00:01] quoi de neuf thecrypto ? [00:01] j'ai ajouté l'utilisateur anonymous avec mot de passe vide, l'ai ajouté aux readers et au cvsgroup et j'obtiens cvs login: authorization failed: server localhost rejected access to /home/cvsgroup/cvsroot for user anonymous [00:01] jrand0m: Bon point. Disons que cette partie de la spécification n'est pas finalisée, et je vais y réfléchir encore. [00:01] cool [00:01] *** LeerokLacerta (~leerok@anon.iip) a rejoint le canal #iip-dev [00:02] Konnichiwa. [00:02] hmm thecrypto, je ne pense pas que tu veuilles un utilisateur OS anonymous [00:02] salut LeerokLacerta [00:02] Bonjour, jrand0m. [00:02] eh bien j'ai mis un mot de passe et maintenant ça marche [00:03] jrand0m: Et si tu as d'autres suggestions après avoir lu la spec, envoie-les-moi. [00:03] je ferai ça co [00:03] cool thecrypto.. est-ce que /bin/false est leur shell ? [00:03] maintenant je dois juste trouver cette section dans le manuel cvs sur comment créer un utilisateur [00:03] -> *thecrypto* c'est quoi le mdp ? [00:04] maintenant oui [00:05] ok, on pourra régler ça après la réunion. [00:05] ok, dernier point à l'ordre du jour : 5b) ? [00:05] des questions / idées / préoccupations ? [00:05] allez juste jeter un œil à l'appli IM [00:06] pour l'instant tout ce que ça fait c'est créer un arbre mais ça vous montre à quoi ça commence à ressembler [00:06] Pas de SOCKS ? [00:06] oh ouais c'est ce que j'ai oublié [00:06] ah cool thecrypto [00:06] SOCKS ? comme dans, le protocole de proxy ? [00:06] quelqu'un ici est bon pour faire des icônes ? [00:06] Oui. [00:06] La réponse à chaque fois que j'ai demandé a été « Non ». [00:07] ah. oui, on va clairement vouloir un proxy socks, mais personne ne travaille dessus pour l'instant. [00:07] Hmm. [00:07] ça fera partie des applis qu'on voudra pour la 1.0 publique, afin que les gens puissent naviguer sur des sites basés sur i2p, et aussi pour que les gens puissent naviguer anonymement sur le web normal [00:07] il y a assez de proxies socks disponibles gratuitement, je dirais ;) [00:08]