I2P Entwicklertreffen - 08. Februar 2022

(03:01:32 PM) eyedeekay: Hallo zusammen, willkommen zur Entwicklerbesprechung am 8. Februar (03:01:38 PM) eyedeekay: Sorry wegen letzter Woche, hoffentlich treten die Probleme mit fallengelassenen Nachrichten nicht wieder auf (03:01:45 PM) eyedeekay: Themen: (03:01:45 PM) eyedeekay: 1. Hi (03:01:45 PM) eyedeekay: 2. Outproxy-Anforderungen (laufend) (03:01:45 PM) eyedeekay: 3. Status 1.7.0/0.9.53 / Release-Zeitplan (03:02:13 PM) zzz: hi (03:02:15 PM) mode (-m ) by zzz (03:02:16 PM) zlatinb: hi (03:02:30 PM) eyedeekay: hi zusammen (03:02:54 PM) eyedeekay: Fangen wir direkt mit 2) Outproxy-Anforderungen an (03:04:08 PM) eyedeekay: zzz hat eine Reihe alter Anforderungsliste gefunden. Wir sollten entweder A) eine auswählen oder B) sie zu einer neuen Liste zusammenführen (03:04:51 PM) eyedeekay: Ich habe versucht zu recherchieren, welche Anforderungen machbar sind, und mir Anregungen geholt, was Tor macht (03:06:18 PM) eyedeekay: Gleichzeitig haben sich einige Gruppen und Einzelpersonen gemeldet, die bei Outproxies helfen wollen, darunter auch ein Betreiber mehrerer Tor-Exit-Knoten, der eine Non-Profit-Organisation betreibt. Hoffentlich können wir von deren Erfahrung profitieren (03:08:04 PM) eyedeekay: In manchen Fällen finde ich die Regeln etwas schwammig: - Optionale Allowlist/Blocklist von Hosts/IPs? Das erscheint auf den ersten Blick einfach, aber was wir auf Host/IP-Basis zum Blockieren/Erlauben vorschlagen, könnte Betreiber Anfragen aussetzen, Dinge zu blockieren, die sie nicht blockieren wollen? (03:08:45 PM) eyedeekay: Es scheint, als sei der Rat gewesen, dass es sicher ist, „Ports“ zu blockieren, aber vielleicht nicht Hostnamen? (03:09:05 PM) zzz: Ich denke, es gibt zwei Kategorien von Anforderungen (03:09:57 PM) zzz: 1) Dinge, die wir als Projekt sehen möchten (Header-Anforderungen, kleine Fehlerseite, Link zu zusätzlichen Infos) (03:10:48 PM) zzz: 2) Dinge, die jeder vernünftige Outproxy-Betreiber möchte, insbesondere Admin-Tools, wozu wir aber nicht die Expertise haben, um viel Anleitung zu geben (03:11:40 PM) zzz: Wir sollten uns auf 1) konzentrieren (03:12:14 PM) eyedeekay: OK, das ist einfacher, es aus der anderen Richtung zu betrachten war wie Pauken für eine Prüfung (03:12:40 PM) zzz: und wir sollten nicht versuchen, für 2) eine schlüsselfertige Komplettlösung anzubieten, höchstens einige Best Practices vorschlagen (03:13:00 PM) eyedeekay: Aber ich denke, das impliziert, dass wir flexibel sein müssen, d.h. Dinge, die wir wollen, werden den Dingen untergeordnet sein müssen, die sie anbieten können (03:13:09 PM) eyedeekay: Das ist aber wahrscheinlich selbstverständlich (03:13:43 PM) zzz: Ich denke, alles in 1) ist ziemlich basic (03:14:38 PM) zzz: 1a) alle ausgehenden X-I2P-Header herausfiltern. Fügt man X-forwarded-Header in eine der beiden Richtungen hinzu oder nicht? (03:14:54 PM) zzz: 1b) eine kleine Fehlerseite mit einem Link zu weiteren Infos (03:15:07 PM) zzz: 1c) eine Datenschutzerklärung auf der Seite mit den zusätzlichen Infos (03:15:13 PM) zzz: so etwas (03:16:24 PM) eyedeekay: Ja, stimme zu, das sollte nicht schwierig sein (03:17:14 PM) eyedeekay: Also werde ich vorerst vermeiden herauszufinden, was Leute in Bezug auf Kategorie 2) „tun sollten“, und mich auf 1) konzentrieren (03:18:19 PM) eyedeekay: Noch etwas zu Thema 2)? (03:18:36 PM) zzz: Die andere Sache in 1) ist http vs. standard tunnel. Ich denke, http ist die richtige Wahl, und die Wahl beeinflusst die Header-Themen (03:19:04 PM) zzz: eot für 2) (03:19:37 PM) eyedeekay: Der standard tunnel fügt die X-I2P-* Header überhaupt nicht hinzu, oder? (03:19:55 PM) zzz: nein, er kennt keine Header (03:20:09 PM) zzz: *Headers (03:20:39 PM) zzz: also beeinflusst die Wahl, was die externe Proxy-Software „sieht“ (03:21:47 PM) eyedeekay: Also warum http? Wäre es nicht besser, wenn die Server-Software die X-I2P-Header nicht entfernen/erneut hinzufügen/nachverfolgen müsste, um ein Leaken zu verhindern? (03:22:23 PM) zzz: Jeder Proxy muss mit Headern umgehen (03:22:49 PM) zzz: der Proxy-Standard gibt an, dass einige Header „hop-by-hop“ sind und entfernt/hinzugefügt werden müssen (03:23:56 PM) zzz: und natürlich gibt es sowohl die HTTP- als auch die HTTPS-(CONNECT)-Fälle zu behandeln (03:27:13 PM) eyedeekay: Im HTTP tunnel-Fall würden wir die X-I2P-Header tatsächlich verwenden (03:28:39 PM) zzz: sie könnten z.B. für Rate-Limiting durch einen kompetenten Outproxy-Admin verwendet werden (03:29:09 PM) eyedeekay: Ergibt Sinn (03:29:57 PM) eyedeekay: Noch etwas zu 2)? (03:30:05 PM) zzz: nein (03:30:12 PM) eyedeekay: 3. Status 1.7.0/0.9.53 / Release-Zeitplan (03:30:59 PM) eyedeekay: Wir sind genau 13 Tage vom Release am 21. entfernt (03:31:10 PM) eyedeekay: Tags werden morgen eingefroren (03:31:39 PM) zzz: yup, Check-in-Deadline Fr., 18. Feb. (03:32:26 PM) zzz: i2pd wird am 19. oder 20. releasen, mit einem Fix für den fiesen SSU-Bug, der in den letzten Monaten Probleme mit der Netzwerkzuverlässigkeit verursacht hat (03:32:55 PM) zzz: unser Release wird auch einige verwandte Workarounds und Verbesserungen enthalten (03:33:09 PM) eyedeekay: Gut zu hören, das war für viele Leute, besonders auf Mobilgeräten, eine harte Zeit (03:33:20 PM) zzz: Ich bin zuversichtlich, dass sich die Lage ziemlich schnell verbessert, sobald die Leute anfangen zu aktualisieren (03:34:10 PM) zzz: abgesehen davon lief der Zyklus ziemlich reibungslos, es wird ruhiger (03:35:26 PM) zzz: wir liegen bei 14.000 Zeilen Diff, eine ziemlich ordentliche Größe (03:36:00 PM) zzz: eot für 3) (03:37:45 PM) eyedeekay: Ich habe nicht viel hinzuzufügen, ich werde in der nächsten Woche noch kleine CSS-Änderungen machen, um einige Macken auf sehr kleinen oder sehr breiten Bildschirmen und ein paar Kontrastprobleme im Dark Theme zu beheben, aber ansonsten werde ich versuchen zu reviewen und zu testen (03:37:55 PM) zlatinb: Ich würde gerne einige Tests im Testnet durchführen, nachdem sowohl i2p als auch i2pd den Code für das Release einfrieren. Ich habe sie im GitLab-Wiki dokumentiert. (03:38:05 PM) zlatinb: eyedeekay: wie steht es um den End-to-End-Test für das Windows AIO? (03:38:58 PM) eyedeekay: Ich habe gestern einen zum Laufen gebracht. Ich hatte ein paar Probleme zu lösen, eins in der Build-Config und eins in der router.config, aber beide sollten jetzt weg sein, solange ich bei meinem Release-Build besonders vorsichtig bin (03:41:18 PM) eyedeekay: Es stellte sich heraus, dass ich das Paket gebaut hatte, ohne die router-Versionsnummer zu erhöhen, also selbst wenn ein Download passiert(was nicht passiert wäre, weil die URL in router.config falsch war), hätte er kein Update ausgelöst (03:42:16 PM) eyedeekay: Beide Probleme sind jetzt behoben und ich habe alles eingerichtet, um das Paket zu testen, nachdem ich es gebaut habe (03:42:49 PM) eyedeekay: Meine Updates waren also schwer kaputt, aber jetzt sollten sie behoben sein, EOT (03:44:07 PM) eyedeekay: Noch etwas für die Sitzung? Fragen, Kommentare, Bedenken? (03:46:02 PM) zzz: aio == "Bundle" oder "Easy-Install-Bundle". Lass uns „aio“ nirgendwo als Namen dafür verwenden (03:46:27 PM) zzz: Ich denke dabei immer an async I/O (03:46:36 PM) zzz: sonst nichts von mir (03:47:06 PM) eyedeekay: OK, ja, AIO ist mehrdeutig, bedeutet für unterschiedliche Leute Unterschiedliches (03:47:28 PM) eyedeekay: Ich bleibe bei Bundle oder Easy-Install-Bundle (03:48:01 PM) eyedeekay: Alles klar, danke an alle fürs Kommen zur Besprechung, bis nächsten Monat am 5., sieht so aus