Réunion des développeurs d'I2P - 8 février 2022

(03:01:32 PM) eyedeekay: Salut tout le monde, bienvenue à la réunion de dev du 8 février (03:01:38 PM) eyedeekay: Désolé pour la semaine dernière, j’espère que les problèmes de perte de messages ne se reproduiront pas (03:01:45 PM) eyedeekay: Sujets: (03:01:45 PM) eyedeekay: 1. Salut (03:01:45 PM) eyedeekay: 2. Exigences pour l’outproxy (proxy de sortie) (en cours) (03:01:45 PM) eyedeekay: 3. statut 1.7.0/0.9.53 / calendrier de sortie (03:02:13 PM) zzz: salut (03:02:15 PM) mode (-m ) by zzz (03:02:16 PM) zlatinb: salut (03:02:30 PM) eyedeekay: salut tout le monde (03:02:54 PM) eyedeekay: Commençons directement par 2) Exigences pour l’outproxy (03:04:08 PM) eyedeekay: zzz nous a trouvé une série d’anciennes listes d’exigences, dont nous devrions soit A) en choisir une, soit B) les rassembler en une nouvelle liste (03:04:51 PM) eyedeekay: J’ai essayé de faire des recherches pour voir quelles exigences sont réalisables et d’obtenir des indications d’après ce que fait Tor (03:06:18 PM) eyedeekay: En même temps, des groupes et des individus se sont proposés pour aider sur les outproxies, dont l’un est aussi opérateur de multiples nœuds de sortie Tor gérant une organisation à but non lucratif, donc on pourra, je l’espère, bénéficier de leur expérience (03:08:04 PM) eyedeekay: Dans certains cas je trouve les règles un peu floues : - Liste d’autorisation/liste de blocage facultative d’hôtes/IP ? par exemple, cela paraît simple au premier abord mais ce que nous suggérons de bloquer/autoriser au niveau hôte/IP pourrait exposer les opérateurs à des demandes de blocage de choses qu’ils ne veulent pas bloquer ? (03:08:45 PM) eyedeekay: Il semble qu’on recommande de bloquer les « ports » mais peut-être pas les noms d’hôte ? (03:09:05 PM) zzz: Je pense qu’il y a deux catégories d’exigences (03:09:57 PM) zzz: 1) Ce que nous, en tant que projet, voudrions voir (exigences d’en-têtes, petite page d’erreur, lien vers des infos supplémentaires) (03:10:48 PM) zzz: 2) Ce que tout opérateur d’outproxy raisonnable voudrait, en particulier des outils d’administration, mais nous n’avons pas l’expertise pour donner beaucoup de directives (03:11:40 PM) zzz: nous devrions nous concentrer sur 1) (03:12:14 PM) eyedeekay: OK c’est plus facile, l’aborder dans l’autre sens c’était comme bachoter pour un examen (03:12:40 PM) zzz: et nous ne devrions pas tenter d’offrir une solution clé en main pour 2), seulement suggérer quelques bonnes pratiques (03:13:00 PM) eyedeekay: Mais je pense que ça implique qu’il faudra être flexibles, c.-à-d. que ce que nous voulons devra passer après ce qu’ils pourront offrir (03:13:09 PM) eyedeekay: C’est probablement acquis, cela dit (03:13:43 PM) zzz: Je pense que tout ce qui est dans 1) est assez basique (03:14:38 PM) zzz: 1a) filtrer tous les en-têtes X-I2P sortants. Faut-il ou non ajouter des en-têtes X-Forwarded dans un sens ou dans l’autre ? (03:14:54 PM) zzz: 1b) avoir une petite page d’erreur avec un lien vers plus d’infos (03:15:07 PM) zzz: 1c) avoir une politique de confidentialité sur la page « plus d’infos » (03:15:13 PM) zzz: des choses comme ça (03:16:24 PM) eyedeekay: Oui je suis d’accord, ça ne devrait pas être difficile (03:17:14 PM) eyedeekay: Donc je vais éviter d’essayer de déterminer ce que les gens « devraient » faire pour la catégorie 2) pour l’instant et me concentrer sur 1) (03:18:19 PM) eyedeekay: Autre chose pour le sujet 2) ? (03:18:36 PM) zzz: L’autre point dans 1) est http vs. tunnel standard. Je _pense_ que http est le bon choix, et ce choix affecte les questions d’en-têtes (03:19:04 PM) zzz: eot pour 2) (03:19:37 PM) eyedeekay: Le tunnel standard n’ajoute pas du tout les en-têtes X-I2P-* n’est-ce pas ? (03:19:55 PM) zzz: non, il ne connaît pas les en-têtes (03:20:09 PM) zzz: *headers (03:20:39 PM) zzz: donc le choix affecte ce que le logiciel de proxy externe « voit » (03:21:47 PM) eyedeekay: Alors pourquoi http ? Ne vaudrait-il pas mieux que le logiciel serveur n’ait pas à retirer/réajouter/suivre les en-têtes X-I2P pour éviter les fuites ? (03:22:23 PM) zzz: tout proxy doit gérer les en-têtes (03:22:49 PM) zzz: la norme des proxies précise que certains en-têtes sont « hop-by-hop » et doivent être retirés/ajoutés (03:23:56 PM) zzz: et bien sûr il faut gérer à la fois les cas HTTP et HTTPS (CONNECT) (03:27:13 PM) eyedeekay: Donc dans le cas du HTTP tunnel on utiliserait effectivement les en-têtes X-I2P (03:28:39 PM) zzz: Elles pourraient servir, par exemple, à la limitation de débit par un admin d’outproxy compétent (03:29:09 PM) eyedeekay: Ça se tient (03:29:57 PM) eyedeekay: Autre chose sur le point 2) ? (03:30:05 PM) zzz: non (03:30:12 PM) eyedeekay: 3. statut 1.7.0/0.9.53 / calendrier de sortie (03:30:59 PM) eyedeekay: Nous sommes exactement à 13 jours de la sortie, le 21 (03:31:10 PM) eyedeekay: Les tags seront gelés demain (03:31:39 PM) zzz: oui, date limite de commit : ven. 18 fév. (03:32:26 PM) zzz: i2pd publiera le 19 ou le 20 avec un correctif pour le méchant bug SSU qui cause des problèmes de fiabilité du réseau depuis quelques mois (03:32:55 PM) zzz: notre version aura aussi des contournements et améliorations associées (03:33:09 PM) eyedeekay: Bonne nouvelle, ça a été difficile pour beaucoup de gens, surtout sur mobile (03:33:20 PM) zzz: J’espère que la situation s’améliorera assez vite dès que les gens commenceront à mettre à jour (03:34:10 PM) zzz: à part ça, le cycle a été assez fluide, les choses se calment (03:35:26 PM) zzz: nous en sommes à 14 000 lignes de diff, belle taille (03:36:00 PM) zzz: eot pour 3) (03:37:45 PM) eyedeekay: Je n’ai pas grand-chose à ajouter, je ferai encore de minuscules changements CSS pendant la semaine qui vient pour gérer quelques bizarreries sur les écrans très petits ou très larges et quelques problèmes de contraste dans le thème sombre, mais à part ça je passerai mon temps à essayer de relire et tester (03:37:55 PM) zlatinb: Je voudrais exécuter quelques tests sur le testnet après que i2p et i2pd auront gelé le code pour la sortie. Je les ai documentés sur le wiki GitLab. (03:38:05 PM) zlatinb: eyedeekay: et le test de bout en bout pour le Windows AIO ? (03:38:58 PM) eyedeekay: J’en ai fait fonctionner un hier, j’avais deux problèmes à régler, un côté build-config et un côté router.config, mais ils devraient être tous deux résolus maintenant tant que je suis très prudent avec mon build de release (03:41:18 PM) eyedeekay: Il s’avère que j’avais construit le paquet sans incrémenter le numéro de version du router donc même si un téléchargement avait eu lieu (ce qui ne se serait pas produit car l’URL dans router.config était erronée) il n’aurait pas déclenché une mise à jour (03:42:16 PM) eyedeekay: Ces deux problèmes sont maintenant corrigés et j’ai mis en place des tests du paquet après l’avoir construit (03:42:49 PM) eyedeekay: Donc mes mises à jour étaient complètement cassées, mais maintenant elles devraient être corrigées, EOT (03:44:07 PM) eyedeekay: Autre chose pour la réunion ? Questions, commentaires, préoccupations ? (03:46:02 PM) zzz: aio == "bundle" ou "easy install bundle". N’utilisons pas « aio » comme nom pour ça où que ce soit (03:46:27 PM) zzz: Je pense toujours à async i/o (03:46:36 PM) zzz: rien d’autre pour moi (03:47:06 PM) eyedeekay: OK oui AIO est ambigu, ça veut dire des choses différentes selon les gens (03:47:28 PM) eyedeekay: Je m’en tiendrai à Bundle ou Easy-Install Bundle (03:48:01 PM) eyedeekay: Très bien, merci à tous d’être venus à la réunion, on se voit le mois prochain le 5, on dirait