Réunion des développeurs I2P - 22 avril 2014

20:32:31 <str4d> Bonjour tout le monde 20:34:53 <str4d> 0) Salut 20:34:53 <str4d> 1) À FAIRE 0.9.13-0.9.16 http://zzz.i2p/topics/1600 20:34:53 <str4d> 2) Nouveau transport pour les PTs (Pluggable Transports de Tor) http://zzz.i2p/topics/1551 20:34:53 <str4d> 3) Tous les points qui émergent du 1) 20:34:53 <str4d> Activité post-réunion : test de charge de Mumble (chat vocal via I2P) 20:35:07 <iRelay> Titre : zzz.i2p : TODO 0.9.13 - 0.9.16 (sur zzz.i2p) 20:35:10 <iRelay> Titre : zzz.i2p : Prise en charge des Pluggable Transports de Tor (sur zzz.i2p) 20:35:29 <str4d> 0) Salut 20:35:57 <hottuna> Bonjour 20:37:37 <str4d> Quelqu'un d'autre ? 20:38:01 <str4d> zzz2 orion psi kytv meeh_ 20:41:17 <str4d> Avec un peu de chance, certains vont se montrer. 20:41:17 <str4d> 1) À FAIRE 0.9.13-0.9.16 http://zzz.i2p/topics/1600 20:41:22 <iRelay> Titre : zzz.i2p : TODO 0.9.13 - 0.9.16 (sur zzz.i2p) 20:41:26 <zzz2> présent 20:41:58 <str4d> À la demande de zzz, nous avons lancé un fil de discussion pour proposer des idées pour la feuille de route I2P à venir. 20:42:27 <str4d> Il y a eu beaucoup de bavardage, mais aucun consensus réel n'a été atteint. 20:43:14 <str4d> J'ai résumé certaines des suggestions initiales sur la page de la feuille de route http://trac.i2p2.i2p/wiki/Roadmaps/1.0 20:43:17 <iRelay> Titre : Roadmaps/1.0 I2P Bugtracker (sur trac.i2p2.i2p) 20:45:01 <str4d> zzz2 : Je vois que tu t'es plongé dans susimail (youpi) 20:46:19 <zzz2> ouais, je suis tombé dans ce terrier pendant qu'on essaie de décider ce qui est vraiment important 20:52:07 <str4d> Je pense que c'était un travail utile, ne serait-ce que parce qu'il y a un bug de longue date sur des problèmes de connexion, et susimail est l'une des premières applis que les utilisateurs vont essayer 20:52:08 <str4d> http://trac.i2p2.i2p/ticket/747 20:52:12 <iRelay> Titre : #747 (Problèmes de connexion avec Susimail) I2P Bugtracker (sur trac.i2p2.i2p) 20:54:45 <psi> str4d: coucou 20:54:47 * psi est en retard ? 20:55:19 <str4d> oui, psi l'est 20:55:25 <str4d> Pas grand-chose ne s'est passé pour l'instant :/ 20:55:58 * psi remonte l'historique 20:56:07 <str4d> Pour résumer ce qui s'est passé depuis la publication de la RFC : 20:56:18 <str4d> - zzz a travaillé sur susimail 20:56:59 <str4d> - psi s'est plongé dans les PTs, le nouveau DH (Diffie-Hellman) et le JNI 20:57:23 <str4d> - J'ai travaillé sur I2P-Bote Android, et maintenant sur EdDSA en Java 20:57:39 * psi a passé toute la journée à étoffer la structure des PT pour i2p 20:58:59 <zzz2> si str4d et psi progressent sur EdDSA, 25519 et les PTs, alors je pense que la meilleure utilisation de mon temps est d'avancer sur la migration vers le nouvel algo de signature, p. ex. plusieurs dests dans un tunnel, et une forme de prise en charge du carnet d'adresses 21:00:27 <jenkins@kyirc> Démarrage du build #581 pour le job I2P 21:01:01 <zzz2> quel est le statut des clés mtn de psi et de l'accord développeur ? Je n'ai rien reçu par la poste. 21:01:23 <str4d> psi a signé l'accord développeur, je l'ai publié sur le site web 21:01:36 <str4d> (donc ses clés publiques sont enregistrées) 21:02:10 <zzz2> son empreinte de clé y est aussi ? 21:02:32 <zzz2> si oui je l'ajouterai et je l'annoncerai 21:03:02 <psi> mon fp gpg est sur mon Twitter 21:03:05 <str4d> pas l'empreinte, mais la clé elle-même oui 21:03:47 <zzz2> il faut que ce soit dans ce fichier modèle d'exemple monotonerc. psi, peut-être que tu peux faire ça comme premier test de tes compétences mtn ? 21:04:23 <jenkins@kyirc> Youpi, build réparé ! 21:04:24 <jenkins@kyirc> Projet I2P build #581 : CORRIGÉ en 3 min 55 s : http://jenkins.killyourtv.i2p/job/I2P/581/ 21:04:36 <psi> je peux m'en charger 21:04:40 <psi> je l'ai déjà fait en local 21:04:53 <str4d> zzz2, psi, j'ai mis à jour le Gantt de la feuille de route - http://trac.i2p2.i2p/wiki/Roadmaps/1.0 21:04:56 <iRelay> Titre : Roadmaps/1.0 I2P Bugtracker (sur trac.i2p2.i2p) 21:05:21 <psi> l'empreinte (fp) de la clé monotone pour ma clé de transport NOT est "1ceb85b992114bae1bcb156ef238f8f3044a6bfe", -- ampernand@gmail.com 21:06:04 <psi> je peux fournir aussi l'empreinte de ma clé de transport 21:06:29 <zzz2> ok super, bienvenue dans l'équipe ! Comme je le dis à tout le monde, sois prudent, entraîne-toi d'abord sur www 21:06:30 <str4d> psi : tu dois envoyer ça à eche, kytv et welt 21:06:43 <str4d> +1 21:06:56 * kytv l'a reçu et l'ajoute à son serveur 21:07:08 <zzz2> psi, nous avons des instructions très précises sur la façon de faire tout ça sur la page web... :) 21:07:27 <psi> je vais regarder ça 21:07:38 <zzz2> par ex., m'envoyer un courrier (mais ce n'est plus nécessaire pour toi) 21:08:15 <str4d> À quoi ressemble le Gantt de la feuille de route pour tout le monde maintenant ? Y a-t-il des éléments qui semblent irréalistes, ou des éléments manquants 21:08:16 <str4d> ? 21:09:37 * psi passe en revue la feuille de route 21:09:43 <jenkins@kyirc> Projet I2P UnitTests build #528 : RÉUSSITE en 5 min 6 s : http://jenkins.killyourtv.i2p/job/UnitTests/528/ 21:09:57 <jenkins@kyirc> Démarrage du build #82 pour le job I2P-Android 21:09:59 <str4d> zzz2 : je suggère que tu règles le point des nouvelles clés GPG plutôt tôt que tard ;) 21:10:19 <zzz2> str4d, dis-nous ce que ça te dit sur ce qui est important 21:10:33 <str4d> psi : trouves-tu beaucoup de recouvrement entre ton travail sur les PTs et NTCP2 ? 21:10:34 <zzz2> oui je le ferai avant la prochaine version, je promets 21:11:24 <str4d> À mon humble avis, il y a trois choses importantes : 21:11:32 <jenkins@kyirc> Projet I2P-Android build #82 : RÉUSSITE en 1 min 34 s : http://jenkins.killyourtv.i2p/job/I2P-Android/82/ 21:11:40 <str4d> 1) des progrès sur la mise à niveau crypto — qui se met enfin en route 21:12:01 <psi> str4d : pour le moment, je n'ai pas encore regardé ntcp2 21:12:13 <str4d> (en continuation du travail de préparation) 21:13:28 <zzz2> 1) « se met en route maintenant » ? Ça fait 6 mois que je bosse comme un dingue dessus 21:13:32 <str4d> 2) Préparation de l'audit — à mon avis nous devons prendre en main notre modèle de menace, etc., dès que possible 21:15:33 * psi s'absente 30 minutes 21:15:33 <psi> événement inattendu, je reviens tout à l'heure 21:15:33 <psi> je regarderai l'historique plus tard 21:16:21 <zzz2> Il semble y avoir de la confusion au sujet de la « nouvelle crypto de signature ». C'est fait, c'est livré dans la 0.9.12, ça marche. Pour destinations (adresses de destination I2P). 21:17:06 <zzz2> La « seule » chose qui n'est pas faite est de migrer les destinations publiées existantes vers une nouvelle. 21:21:13 <str4d> oui, ce qui repose d'abord sur le choix d'une nouvelle, qui à mon avis devrait être Ed25519, ce qui nécessite d'obtenir une implémentation rapide. 21:21:15 <str4d> Et en même temps, je suis d'accord pour dire que l'infrastructure de migration restante nécessaire devrait être mise en place. 21:21:16 <str4d> <str4d> Pendant des années nous l'avons laissé de côté et nous avons travaillé sur ce que nous pensons bénéfique aux utilisateurs, mais à mon avis si nous voulons susciter plus d'intérêt de la recherche, et l'utiliser efficacement, nous devons être plus conscients de ce que I2P peut et ne peut pas accomplir. 21:21:17 <str4d> <str4d> Je sais que tu l'as fait zzz ;P 21:21:18 <str4d> <str4d> (je faisais spécifiquement référence à la partie impliquant la nouvelle crypto à proprement parler) 21:21:19 <str4d> <str4d> merci pour l'effort que tu as fourni pour l'amener jusque-là :) 21:21:20 <str4d> <str4d> 3) Utilisabilité, UX — c'est un troisième point important qui n'est pas sur le graphique de la feuille de route 21:21:22 <str4d> <str4d> Eh bien — le travail de zzz sur susimail tombe dans cette catégorie, tout comme les améliorations du streaming 21:21:41 <str4d> <str4d> Mais il est aussi important de revoir nos pages d'erreur et d'aide, et la manière dont nous aidons l'utilisateur à accomplir ses tâches. 21:21:41 <str4d> (après ma ligne « 2) Préparation de l'audit ») 21:22:00 <str4d> Je dois passer AFK dans 10-15 min 21:22:50 <str4d> Et puisque psi est AFK, je retire « 2) Nouveau transport pour les PTs de Tor » de cette réunion 21:23:55 <str4d> zzz2 : à ton avis, que devons-nous faire avant d'organiser une réunion avec Lance au sujet du modèle de menace ? 21:24:59 * str4d aimerait tenter une réunion avec Lance en mai 21:26:04 <str4d> donc nous devons déterminer ce que nous devons faire d'ici là, afin de pouvoir organiser la réunion avec suffisamment de temps pour terminer cela d'abord. 21:29:27 <zzz2> Je ne suis pas d'accord sur le fait qu'il faille d'abord choisir. 21:29:59 <zzz2> Ou, que nous pouvons choisir maintenant (P256) et choisir à nouveau plus tard quand plus d'options seront disponibles. 21:30:02 <MTN@kyirc> [ I2P ] correction de compilation [zzz@mail.i2p] http://killyourtv.i2p/viewmtn/revision/info/12396c3ee88d1194482fc2cc3751db1169cc52e3 21:30:34 <zzz2> On pourrait passer la valeur par défaut pour les nouveaux dests à P256 dans la 0.9.13 si on veut. 21:30:35 <str4d> zzz2 : si nous arrivons à un stade où le système de nommage peut gérer des choix d'enc dynamique, alors je suis d'accord 21:31:05 <zzz2> P256 est clairement meilleur que DSA 21:31:34 <str4d> Je suis d'accord là-dessus aussi. 21:31:43 <zzz2> Je pense que les détracteurs de P256 feraient bien de prendre du recul et de réfléchir à quel point DSA 1024 est mauvais. 21:32:03 <MTN@kyirc> [ WWW ] ajout de la clé de transport de psi [kytv@mail.i2p] http://killyourtv.i2p/viewmtn/revision/info/029163d2d446f10ab1a129b559802fabac2ef8b7 21:32:52 <str4d> zzz2 : je comprends ton point de vue. 21:33:39 <zzz2> à propos de l'audit et de Lance, c'est toujours le bon moment. tu as une mise à jour sur le processus d'audit pour nous, depuis la liste de diffusion ? 21:33:40 <str4d> Une partie de la raison pour laquelle je veux faire fonctionner EdDSA avant le basculement est que, d'après ce que tu as dit dans des fils auparavant, je n'ai pas hâte de changer deux fois l'algo de signature des Dest. 21:34:14 <str4d> oui, la deuxième fois serait un peu plus facile parce que la prise en charge multi dest, etc., serait là, mais la partie nommage reste la faiblesse. 21:34:48 <zzz2> pour les serveurs on ne veut pas changer deux fois, mais pour les clients ça n'a pas d'importance 21:35:04 <str4d> bon point. 21:35:23 <str4d> Y a-t-il quelque chose qui empêcherait de nouveaux Dests de parler avec les anciens ? 21:35:31 <nombre_> donc je comprends que vous faites des mises à niveau crypto ? y a-t-il peut-être une page qui détaille tout ce que vous prévoyez ? et pour une implémentation 25519, vous pourriez simplement utiliser NaCl via JNI, ou Kalium, même si ça pourrait être quelque peu limitant 21:35:34 <zzz2> et même pour les serveurs, si tu passes à P256 ça ne semble guère valoir le coup de changer à nouveau, à moins que de très mauvaises nouvelles ne sortent à propos de P256 21:35:54 <str4d> Sinon, ça pourrait être une bonne idée de faire passer les clients sur P256 plus tôt 21:36:08 <zzz2> les nouveaux dests peuvent parler aux anciens et vice versa, tant que les deux sont en 0.9.12 ou plus 21:36:39 <str4d> zzz2 : http://blog.cr.yp.to/20140323-ecdsa.html est une raison suffisante pour moi pour ne pas vouloir rester sur ECDSA 21:36:43 <iRelay> Titre : cr.yp.to : 2014.03.23 : How to design an elliptic-curve signature system (sur blog.cr.yp.to) 21:37:56 <str4d> pas pour un point précis (pour l'instant), mais si nous pouvons obtenir une implémentation EdDSA efficace et correcte, je pense qu'il serait très bénéfique de basculer 21:38:27 <str4d> nombre_ : http://trac.i2p2.i2p/ticket/856 21:38:30 <iRelay> Titre : #856 (Revue/migration crypto) I2P Bugtracker (sur trac.i2p2.i2p) 21:38:30 <str4d> (et les liens qui s'y trouvent) 21:38:40 <nombre_> merci str4d 21:38:53 <zzz2> rien là-dedans ne me dit de retarder l'abandon de DSA pour autant. Il n'y a rien non plus qui me fasse paniquer au sujet de P256. Y a-t-il mieux que P256 ? bien sûr. 21:39:15 <str4d> zzz2 : pas de vraie mise à jour en tant que telle depuis la liste de diffusion OpenITP, il n'y a pas eu beaucoup d'activité réelle dernièrement. 21:40:38 <zzz2> J'ai prévu 65536 algos de signature et j'en ai implémenté 7. 65529 à faire, on peut en ajouter quelques-uns à chaque version si on veut. 21:43:27 <str4d> zzz, je serais pour faire passer les clients à p256 dans la 0.9.13 21:44:47 <str4d> mais si la transition côté serveur n'est toujours pas fluide, je préférerais attendre un peu et voir comment avancent les travaux sur EdDSA. 21:45:49 <nombre_> moi aussi (même si mon opinion ne compte pas pour grand-chose), l'ECDSA NIST est meilleur que DSA, même si certains d'entre nous, paranoïaques, ne se sentiront en sécurité qu'avec 25519 21:46:48 <nombre_> la rupture dest/b32 est en quelque sorte acquise, non ? 21:47:13 <str4d> il a fallu beaucoup de temps et de travail pour en arriver là, ça n'a pas de sens de se précipiter à la dernière minute 21:49:48 * RN passe la tête et regarde autour 21:54:36 <zzz2> il y a 1) les clients 2) les nouveaux serveurs et 3) la migration des serveurs existants. 21:54:43 <zzz2> 1 et 2 on peut les faire maintenant, 3) demande beaucoup plus de travail. 21:54:59 <zzz2> 1 et 2 cassent la compatibilité avec les anciens routers, i2pcpp et i2pd, jusqu'à ce qu'ils rattrapent leur retard 21:55:16 <nombre_> donc, quelqu'un travaille-t-il à trouver/créer une implémentation Java de 25519 ? et quel est le délai estimé avant qu'elle soit utilisable ? 21:55:28 <nombre_> je suppose qu'avec p256, c'est déjà faisable parce que c'est inclus dans Bouncy Castle ? 21:55:52 <zzz2> p256 est dans la JVM 21:56:06 <nombre_> ah, encore mieux 21:56:17 <zzz2> nous avons 25519 en Java maintenant mais c'est beaucoup trop lent pour être utilisable. str4d et psi essaient de l'accélérer 21:57:39 <nombre_> hmm, ne connaissant rien à la crypto, je penserais que l'utilisation de JNI serait la façon la plus simple de l'accélérer. peut-être que je devrais regarder 25519 de plus près pour comprendre quelles en sont les parties goulots d'étranglement 23:02:36 <str4d> Personne ne l'a réellement terminée quand je suis passé afk, donc : 23:02:53 * str4d *baf* clôt la réunion.