I2P Entwicklertreffen - 1. Februar 2005

13:06 <jrandom> 0) hi 13:06 <jrandom> 1) 0.5-Status 13:06 <jrandom> 2) nntp 13:06 <jrandom> 3) technische Vorschläge 13:06 <jrandom> 4) ??? 13:06 <jrandom> 0) hi 13:06 * jrandom winkt 13:06 <+postman> hi jr 13:07 * postman winkt 13:07 <jrandom> w3wt da draußen gibt es doch Leben :) 13:07 <jrandom> Wöchentliche Statusnotizen sind unter http://i2p.net/pipermail/i2p/2005-February/000561.html veröffentlicht 13:07 <ant> * dm winkt 13:08 <jrandom> Während ihr alle diese E-Mail lest, können wir zu 1) 0.5-Status übergehen 13:08 <MANCOM> hi 13:09 <jrandom> Viel Fortschritt in der letzten Woche, die ganze neue Krypto ist drin und getestet, und jetzt läuft der gesamte Betrieb des router mit den tunnel über die neuen tunnel-Pools 13:10 <jrandom> Es gibt noch einige Teile des router, die ich beim Update herausgeschnitten habe, z. B. die Anbindung, um Leases von Clients anzufordern, oder die tunnel periodisch zu testen, aber das sollte nicht allzu schwierig sein 13:11 <jrandom> Der Code ist nicht mit dem Live-Netz kompatibel und liegt in einem separaten Branch in CVS, sodass Leute weiterhin CVS-HEAD ziehen und mit dem neuesten Stand arbeiten können. 13:12 <+polecat> Dook, ich habe mir diese Seite endlich angesehen, und ich verstehe immer noch nicht, wie wir Mixmaster-artige Redundanz vermeiden können, um uns vor tunnel-Detektionsangriffen zu schützen. 13:12 <+protokol> yey 13:12 <+polecat> Ich nehme aber an, dass es sehr gut funktioniert. :) 13:12 <+protokol> Wirfst du noch anderes cooles, kompatibilitätsbrechendes Zeug rein? 13:13 <+protokol> Der tunnel-Pool hat mit Threads zu tun, oder? 13:13 <jrandom> polecat: Wir verifizieren nicht an jedem Hop, aber wir haben eine feste Nachrichtengröße, um nützliches Tagging zu verhindern (und alles ist an jedem Hop verschlüsselt) 13:14 <jrandom> protokol: Ich erwäge http://www.i2p/todo#sessionTag 13:14 <+polecat> Also, wie verhindern wir, dass mehrere Hops gefälschte Nachrichten herumreichen und damit einen DoS verursachen? 13:15 <jrandom> Aber nein, die Pools sind nicht das Threading-Problem; die Pools ermöglichen uns lediglich, die tunnel sicher zu verwalten, sodass wir diese "Lease expired"-Meldungen nicht bekommen und die Länge pro Client konfigurieren können 13:15 <jrandom> polecat: Sie schlagen am Endpunkt fehl, und der Ersteller erkennt den Fehler und wechselt davon weg 13:16 <+protokol> jrandom: Ungeachtet der Schwierigkeiten denke ich, dass alle Anonymitäts-verbessernden Features so schnell wie möglich rein sollten 13:16 <+polecat> w00t! Synchronisierte PRNG! Erste Anwendung dieser Idee, die ich je gesehen habe! 13:17 <ant> <dm> wofür steht PRNG? 13:17 <ant> <dm> wenn ich fragen darf :) 13:18 <jrandom> protokol: Einverstanden, dafür ist 0.5 da :) Auf der i2p-Schicht gibt es keine weiteren Low-Hanging Fruit, aber auf App- und Lib-Ebene gibt es immer Verbesserungen (z. B. i2ptunnel filtering, etc) 13:18 <jrandom> dm: Pseudozufallszahlengenerator 13:18 <ant> <dm> cool, danke 13:20 <+protokol> Also sagst du, dass es danach größtenteils um Speed- und Zuverlässigkeits-Tuning geht? 13:21 <+protokol> Und warum war IRC in letzter Zeit so mies 13:21 <jrandom> protokol: Vor 2.0 für den Core und den router, ja 13:21 <+protokol> Ich scheine mich nicht mit ducks Server verbinden zu können 13:21 <+protokol> yey 13:21 * jrandom weiß es nicht, wir haben in den letzten 24 Stunden etwa 5 Massen-Disconnects gesehen, vielleicht etwas auf der Serverseite 13:22 <jrandom> Es gibt allerdings viel zu tunen, besonders in der Streaming-Bibliothek, nachdem 0.5 ausgerollt ist 13:23 <+polecat> Dieses ganze UDP-Ding. 13:24 <jrandom> Ah, die Streaming-Bibliothek sollte für das 0.6-Release keine Änderungen benötigen, außer denen, die wir für den 0.5-Stand machen 13:25 <jrandom> Ok, das ist alles, was ich bzgl. 0.5-Status ansprechen wollte - hat jemand noch etwas dazu? 13:27 <jrandom> Wenn nicht, weiter zu 2) nntp 13:27 <jrandom> nntp.fr.i2p ist online, schaut’s euch an :) 13:28 <jrandom> Es scheint, als wäre LonelyGuy nicht da, aber er ist unter http://fr.i2p/ erreichbar. es gibt auch Konfigurationsanleitungen für slrn in meinem Blog, und jdot hat herausgefunden, dass thunderbird ziemlich sicher sein kann (obwohl ich nicht weiß, welche Config jdot verwendet hat) 13:30 <smeghead> LonelyGuy? :) 13:30 <cervantes> Hat jemand auch Pan getestet? 13:30 <jrandom> Er war gelegentlich hier 13:30 <+polecat> Ich würde nicht zu viel Zeit auf nntp verwenden, aber solange es eine vom Nutzer verwaltete Zugangskontrolle hat, ist es ok. 13:30 <jrandom> (lonelyguy, nicht pan ;) 13:30 <smeghead> Ich dachte, sein Name wäre LazyGuy 13:31 <jrandom> Ist es LazyGuy? 13:31 <jrandom> Ich weiß, wir hatten beide... 13:31 <jrandom> Du hast recht, lazyguy 13:31 * jrandom !sticht sich selbst 13:31 <jrandom> cervantes: Ich glaube, LazyGuy hat es ausprobiert, ich kenne die Config oder das Ergebnis aber nicht 13:32 <cervantes> Ich dachte, es wäre LimeyGuy? 13:33 * jrandom wartet auf die Kommentare von SnarkeyGuy 13:33 <smeghead> Er ist Franzose 13:35 <jrandom> Ok, mehr habe ich dazu nicht, also wenn niemand Fragen hat, weiter zu 3) technische Vorschläge 13:35 <cervantes> smeghead: Du meinst ParesseuxGuy 13:36 <jrandom> orion hat ein paar gute Beschreibungen und Ideen zu einigen der kniffligeren Themen zusammengestellt, oben bei 1) 0.5-Status 13:36 <jrandom> 2) nntp 13:36 <jrandom> 3) technische Vorschläge 13:36 <jrandom> erg 13:36 <jrandom> verdammt ^C^V 13:36 <jrandom> unter http://ugha.i2p/I2pRfc nämlich 13:37 <jrandom> Also, wenn ihr das nächste Mal eure Killer-Idee für Namensgebung diskutieren wollt, geht zu http://ugha.i2p/I2pRfc/I2pRfc0001ResourceNameMetadata 13:39 <jrandom> Viel mehr habe ich dazu nicht. Es ist ein Wiki, also legt los mit dem Wiki :) 13:39 <+polecat> Yay. 13:39 <+postman> jrandom: Ohh, cool, ich glaube, ich muss ein paar hinzufügen ... 13:40 <jrandom> Cool, postman, dachte ich mir :) there's a template up there for new ones 13:41 <+postman> jrandom: Gib mir ein bisschen Zeit (erst die wichtigen Dinge) aber ich werde beitragen :) 13:41 <jrandom> w3rd 13:41 <+polecat> ResourceNameMetadata, es zu bilden ist relativ trivial. Der Trick ist herauszufinden, wie man es von anderen Leuten /bekommt/. 13:42 <jrandom> polecat: Wie postman sagte: erst die wichtigen Dinge. 13:42 <+polecat> Aber wenn ich eine Lösung hätte, würde ich jetzt wohl wiki'n, oder? :) 13:42 <jrandom> heh 13:42 <jrandom> Eine Diskussion der Trade-offs des /Wie/ der Verteilung, bevor entschieden ist, /Was/ verteilt werden soll, ist verfrüht 13:43 <jrandom> Es ist aber Platz für viele davon, also sollte sich jeder frei fühlen, auch noch nicht vollständig durchdachte Ideen zu posten (obwohl vollständig funktionierende mit Implementierungen auch cool wären ;) 13:44 <jrandom> Ok, wenn es dazu nichts Weiteres gibt, können wir vielleicht zum guten alten 4) ??? übergehen 13:44 <jrandom> Hat sonst noch jemand etwas anzusprechen? 13:45 <jrandom> smeghead: Gibt es etwas, das Leute tun können, um bei den gcj-Problemen zu helfen, oder hängt es an deren PRNG? 13:46 <+polecat> Was verteilt wird, ist einfach ein signiertes Dict. So einfach ist das. 13:46 <+polecat> Ja, wahrscheinlich eine gute Idee. 13:46 <+polecat> Ich arbeite IMMER NOCH am Gerüst für meinen i2p-bt-Client, würde aber jederzeit Ratschläge sehr schätzen. 13:46 <smeghead> Ich glaube, ich habe eine Lösung gefunden 13:46 <smeghead> In gnu crypto gibt es seit letztem Sommer eine Fortuna-Impl. 13:46 <jrandom> Schön, polecat 13:46 <jrandom> Oh, cool, smeghead 13:46 <+polecat> smeghead: Hehe, die $150 gehören dir so gut wie. 13:47 <smeghead> Ich kann ein gnu-crypto.jar zusammenstellen, das nur die für Fortuna benötigten Klassen enthält 13:47 <+polecat> Meine bisherigen Arbeitsnotizen sind unter http://polecat.i2p/bittorrent.plan.doc 13:47 <smeghead> Wenn wir das gesamte gnu-crypto.jar ausliefern, sind es etwa 500 KB, wirklich zu groß 13:47 <+polecat> Lass dich von der .doc nicht erschrecken, es ist in text/plain. 13:48 <+polecat> Verwendet Fortuna nicht SecureRandom, um Zufälliges zu tun? 13:48 <jrandom> Yowza, ja, 500KB ist etwas übertrieben, aber beim Blick auf http://www.gnu.org/software/gnu-crypto/ sieht es nach etwas aus, das wir sicher integrieren könnten (da wir nur dagegen linken würden, nicht es modifizieren) 13:48 <smeghead> SecureRandom war nie das Problem 13:48 <jrandom> polecat: fortuna /füttert/ secureRandom :) 13:49 <smeghead> jrandom: Es wäre einfach, ein benutzerdefiniertes .jar zu bauen, wahrscheinlich um die 50KB 13:49 <smeghead> (wohlgemerkt grobe Schätzung) 13:49 <smeghead> Ich könnte sogar einen Ant-Build machen, um es bei Bedarf benutzerdefiniert zu packen 13:50 <jrandom> smeghead: Willst du’s unter i2p/apps/fortuna/ einhängen? 13:50 <smeghead> Mache ich 13:50 <jrandom> Geil! 13:51 <smeghead> Danach, vorausgesetzt gcj spuckt endlich Zufallszahlen aus, wird es wahrscheinlich mehr Tests verschiedener i2p-Funktionalitäten geben 13:51 <+polecat> Was ist die Lizenz? 13:51 <jrandom> Wir können dann etwas Voodoo in net.i2p.util.RandomSource machen, um entweder SecureRandom oder fortuna zu verwenden (falls gefunden usw.) 13:51 <smeghead> lgpl 13:51 <+polecat> Cool. 13:51 <smeghead> Stimmt, SecureRandom wäre unnötig 13:52 <jrandom> Ja, es gibt noch viel zu tun, um es gcj‑fähig zu machen, aber es ist ein großartiger Start 13:52 <jrandom> In den Profilen, die ich im Live-Netz gemacht habe, nimmt das Neu-Seeden des PRNG einen guten Teil der CPU-Last ein 13:52 <smeghead> Falls jemand Lust hat, Tests zu schreiben 13:52 <smeghead> aber ich muss diesen Satz wohl nicht beenden 13:52 <jrandom> hehe 13:53 <smeghead> Ich werde den gnu-crypto-Maintainer nach dieser Impl. fragen, weil ich nach Infos dazu gegoogelt und die Mailinglisten-Archive durchsucht habe und es dazu keinen Mucks gibt 13:54 <smeghead> Und ihre CVS-Commit-Logs sind auch nicht allzu erhellend 13:54 <jrandom> 'k gute Idee 13:54 <smeghead> Ich hoffe, es funktioniert 13:54 <smeghead> Es ist btw im Kaffe-CVS 13:54 <smeghead> Deine Version sollte es sogar haben 13:55 <jrandom> Hmm, ah, ja, vom gnu-crypto-Import 13:55 <smeghead> gnu.security.prng.Fortuna 13:55 <jrandom> Der 'kaffe'-Provider verwendet immer noch ihren alten sha1prng, iirc 13:55 <jrandom> cool 13:56 <MANCOM> Wie ist der Status der .net sam Sachen? sollte man anfangen, sich damit zu beschäftigen oder sind größere Änderungen zu erwarten? 13:56 <smeghead> MANCOM: Es braucht Tests, ich werde bald ein paar Unit-Tests dafür schreiben 13:56 <smeghead> Diese gcj-Sache hat das etwas auf Eis gelegt 13:57 <smeghead> MANCOM: Ich erwarte überhaupt keine Änderungen an der API, also sollte es sicher sein, dagegen zu programmieren 13:58 <smeghead> Änderungen hinter der API sind wahrscheinlich, aber du als Client musst das nicht wissen :) 13:59 <MANCOM> :) 13:59 <jrandom> Später könnte es ein paar Updates geben, die relevant sind, wenn du Apps baust, die große Bulk-Transfers machen 14:00 <jrandom> Aber wenn du nur jeweils einige 10s of KB überträgst, sollte es passen 14:00 <smeghead> Ok wenn sich die API des Java-Clients ändert, dann die des sam-sharp auch :) 14:01 <MANCOM> Dagegen kann ich nichts einwenden 14:02 <jrandom> Ok, hat jemand noch etwas fürs Meeting anzusprechen? 14:02 * cervantes senkt Big Ben in den Channel 14:03 <+DrWoo> Hinweis: gute Arbeit jrandom 14:03 <smeghead> Gutes Wortspiel, cervantes 14:03 * jrandom stöhnt 14:04 <MANCOM> Ich habe gelesen, dass ihr i2p vor v0.5 nicht zu sehr bewerben wollt, stimmt das? 14:04 <jrandom> MANCOM: vor 0.6. ja 14:04 <jrandom> MANCOM: 0.5 wird die Anonymität verbessern und den Nutzern helfen, ihre Performance besser zu steuern. 0.6 wird es Tausenden+ gleichzeitigen Nutzern erlauben, sicher zu operieren 14:04 <MANCOM> Ah. 0.6. ok. 14:05 <jrandom> gracias, Doc, viel Fortschritt :) 14:05 <+polecat> Whee, ich freue mich auf 0.6... 14:05 <+DrWoo> :) 14:06 <jrandom> Einverstanden, polecat, einverstanden :) 14:06 * jrandom holt aus 14:06 * jrandom *baf*t das Meeting zu