Kurzer Überblick

Anwesend: cervantes, jrandom, kostya213, modulus, tethra, vulpine

Sitzungsprotokoll

16:06 <jrandom> 0) hi 16:06 <jrandom> 1) 0.6.1.25 und Netzstatus 16:06 <jrandom> 2) I2PSnark 16:06 <jrandom> 3) Syndie (was/warum/wann) 16:06 <jrandom> 4) Syndie-Krypto-Fragen 16:06 <jrandom> 5) ??? 16:06 <jrandom> 0) hi 16:06 * jrandom winkt 16:06 <jrandom> Wöchentliche Statusnotizen veröffentlicht unter http://dev.i2p.net/pipermail/i2p/2006-September/001307.html 16:07 <jrandom> Da diese Notizen vor Stunden und Aberstunden herauskamen, solltet ihr sie schon gelesen haben und Notizen parat haben, oder? ;) 16:07 <jrandom> springen wir vor zu 1) 0.6.1.25 und Netzstatus 16:08 <vulpine> <Complication> Bezüglich 0.6.1.25: Lief hier einwandfrei, nur ein bisher nicht gesehener Fehler 16:08 <jrandom> cool, was ist das Problem? 16:08 <vulpine> * Complication durchsucht Logs 16:09 <jrandom> Die Netzgröße scheint größer als zuvor, allerdings immer noch gleiche Größenordnung 16:09 <vulpine> <Complication> "Unknown error reading the net.i2p.data.i2np.GarlicMessage: wtf, fromLong got a negative? -840" 16:10 <vulpine> <Complication> Begann mit "ERROR [NTCP read 1 ] .router.tunnel.FragmentHandler: Error receiving fragmented message (corrupt?)" 16:10 <jrandom> ah ok cool, den gibt es schon lange, kann man ignorieren 16:11 <vulpine> <Complication> Einmaliges Auftreten 16:11 <vulpine> <frosk> Ich habe von dem letzten mehrere bekommen 16:11 <vulpine> * jrandom stupst fox 16:12 <vulpine> <Complication> Oh, und noch einer: "router.tunnel.TunnelDispatcher: wtf, took 1121 to dispatch net.i2p.data.i2np.TunnelBuildMessage@XXXX out YYYYY in net.i2p.router.tunnel.PumpedTunnelGateway@ZZZZ" 16:12 <vulpine> <Complication> (wirkt auch unwesentlich, vielleicht nur einfache Überlastung) 16:12 <jrandom> ja, wahrscheinlich 16:13 <jrandom> IRC ist momentan offensichtlich noch etwas holprig 16:13 <jrandom> (aber ausnahmsweise ist es nicht die Schuld von i2p :) 16:14 <jrandom> ok, hat noch jemand etwas zu 1) Netzstatus und 0.6.1.25? 16:15 <kostya213> Wollte nur hinzufügen, dass .25 alle Probleme behoben hat, die ich in den letzten Monaten hatte 16:15 <jrandom> genial! 16:16 <vulpine> <green> bitte ändere die Statusberechnung, wenn nur NTCP verwendet wird 16:16 <jrandom> 'k, aber es ist nicht empfohlen, udp zu deaktivieren (ich glaube, ich habe ausdrücklich gesagt, dass ich den Leuten auch nicht erkläre, wie man udp deaktiviert) 16:17 <jrandom> aber der Status sollte aktualisiert werden, um zu berücksichtigen, dass udp nicht der einzige Transport ist 16:17 <jrandom> Ich werde das in der nächsten Revision beheben, danke 16:17 <vulpine> <green> klar, du sagst es nicht, aber ich kann Code lesen ;) 16:18 <jrandom> schon, aber wenn ich etwas nicht empfehle und den Leuten sage, sie sollen es nicht einmal versuchen, dann sei nicht überrascht, wenn eine Anzeige verwirrend ist ;) 16:19 <vulpine> <green> sicher, ich könnte auch einfach "OK" in der Konsole anzeigen :) 16:19 <jrandom> schon wahr 16:21 <jrandom> ok, springen wir rüber zu 2) I2PSnark 16:21 <jrandom> zzz scheint gerade nicht da zu sein 16:22 <jrandom> zzz arbeitet an einigen Änderungen, um das Scheduling in i2psnark zu verbessern 16:23 <jrandom> (es ist im Moment etwas... schlicht, soweit ich mich erinnere, allerdings bin ich mir der Modifikationen, an denen zzz herumhackt, nicht ganz sicher) 16:23 <jrandom> ((aber ich freue mich auf die Fortschritte!)) 16:25 <jrandom> ok, wenn es nichts Weiteres zu 2) I2PSnark gibt, gehen wir weiter zu 3.*) Syndie-Kram 16:26 <jrandom> Fangen wir zunächst mit 3.1) Was ist Syndie an, da es so viel zu behandeln gibt 16:27 <jrandom> Ich habe vor dem Treffen ein paar Fragen zur Verschlüsselung von Beiträgen bekommen 16:27 <jrandom> Grundsätzlich sind Beiträge *symmetrisch* verschlüsselt – jeder mit dem symmetrischen Schlüssel kann den Beitrag lesen, da er autorisiert ist 16:28 <jrandom> Antworten eines Channels werden asymmetrisch an den öffentlichen Schlüssel verschlüsselt, der dem Channel/Forum zugeordnet ist 16:28 <jrandom> Einige Beiträge können passphrasenbasierte Verschlüsselung verwenden, um den symmetrischen Schlüssel zum Lesen zu erzeugen 16:29 <jrandom> Und einige Beiträge können den symmetrischen Schlüssel in den lesbaren Headern des Beitrags enthalten (sodass ihn jeder lesen kann) 16:29 <modulus> Was ist der Sinn von letzterem? 16:29 <jrandom> Und einige Foren selbst können den symmetrischen Schlüssel in den Forum-Metadaten enthalten, sodass jeder den Beitrag lesen kann, aber nur, wenn er die Channel-Metadaten hat 16:29 <jrandom> modulus: damit alles immer verschlüsselt ist, sogar öffentlich lesbare Dinge 16:29 <jrandom> (damit triviales Abhören nutzlos ist) 16:30 <modulus> okay, verstehe. 16:31 <jrandom> ok, ich denke, das deckt die Verschlüsselungsfragen ab, die vor dem Treffen gestellt wurden 16:31 <jrandom> Hat jemand Fragen zu 3.1) Was ist Syndie? 16:31 <jrandom> (Ich meine, mehr wird sich natürlich klären, wenn es draußen ist) 16:32 <vulpine> <void> hmm 16:33 <jrandom> wie geht's, void? 16:33 <vulpine> <void> <void> Ich nehme an, dass das Nachrichten- (.zip-)Archiv auch andere Nachrichten enthalten kann, möglicherweise von anderen Leuten, etwa die zitierten Nachrichten? 16:34 <jrandom> Nun, ja, man kann .snd-Dateien als Anhänge einfügen, aber es gibt einen expliziten Namespace, sodass man Verweise im Standardstil „References:“ auf frühere Nachrichten setzen kann 16:34 <jrandom> (sprich, man muss kein Frost-Style-„Threading“ machen) 16:35 <vulpine> <void> ok, alles klar 16:37 <vulpine> <Complication> Zu Syndie: Ich habe mich gefragt, wie man das Problem löst, Leuten Zugang zu einem Forum mit mehreren Postern zu geben (wie Konten in einem gewöhnlichen Messageboard), dies aber nicht unwiderruflich zu gewähren und unerwünschtes Chaos zu vermeiden, wenn der Zugang aus irgendwelchen Gründen widerrufen werden muss 16:38 <vulpine> <Complication> Eine Lösung schien natürlich, dass der Autor eine Empfehlung angibt, wessen Antworten Clients anzeigen sollen 16:38 <jrandom> Complication: ein neues Public/Private-Keypair erstellen, den privaten Schlüssel an (vorübergehend) autorisierte Personen geben und den öffentlichen Schlüssel als Liste der „keys allowed to post“ aufnehmen 16:38 <vulpine> <Complication> ...und Clients, sofern sie nicht die Historie erforschen wollen, dieser Empfehlung folgen (genauer gesagt ihrer neuesten Version) 16:38 <jrandom> (und wenn sie nicht mehr autorisiert sind, diesen Schlüssel aus der Liste der „keys allowed to post“ entfernen) 16:39 <kostya213> jrandom: Du solltest vielleicht eine andere Extension als .snd verwenden, da das eine weit verbreitete Erweiterung für Audioanwendungen ist; MIME wird das verwechseln 16:39 <jrandom> ah, richtig – alle Foren haben einen „Owner“ (einen signierenden privaten Schlüssel), der die Liste verwalten kann, wer posten darf usw. 16:39 <vulpine> <Complication> „keys allowed to post“ wären Metadaten, die am letzten Beitrag des Autors hängen, oder an irgendeiner anderen Nachricht, richtig? 16:39 <jrandom> Guter Punkt, kostya213, dann bleiben wir vielleicht bei .dat hängen ;) 16:40 <jrandom> Complication: ah sorry, nein, es ist wie beim aktuellen/alten Syndie – separate signierte Metadaten-Beiträge für das Forum/den Channel selbst 16:40 <vulpine> * Complication glaubt, dass sogar jemand .dat schon für irgendwas beansprucht hat :) 16:40 <jrandom> ja, die Anwendung namens „octet-stream“ ;) 16:40 <vulpine> <void> Sieht nicht so aus, als würde .syn für etwas Bemerkenswertes verwendet 16:41 <vulpine> <Complication> Aha, spezielle Metadaten-Beiträge... okay, das könnte funktionieren 16:41 <jrandom> oh fein, wir kommen zu syn! 16:41 <jrandom> (gutes Auge, void, danke kostya213) 16:41 <vulpine> <void> hmm, 16:41 <vulpine> <void> hmm, „Word Synonym File“, Firma: Microsoft 16:42 <jrandom> nun, ich bin sicher, wir kriegen das hin 16:42 <kostya213> ja, wird von Word verwendet 16:42 <vulpine> <void> aber wir könnten das ebenso gut ignorieren :) 16:42 <kostya213> Nicht die Hoffnung verlieren, ich denke, es lässt sich etwas finden, das keine Probleme mit weit verbreiteten MIME-Typen verursacht 16:43 <jrandom> ok, noch etwas zu 3.1) Was ist Syndie? 16:43 <vulpine> <void> äh, andererseits, warum sollten wir an drei Buchstaben langen Erweiterungen festhalten? Das ist ein Relikt aus den DOS-Zeiten 16:43 <kostya213> eine Sache muss gefragt werden: Warum auf eine dreibuchstabige Erweiterung beschränken? Niemand nutzt DOS mehr 16:44 <jrandom> heh 16:44 <kostya213> jinx mit void 16:44 <kostya213> .syndie scheint mir gut zu sein 16:44 <vulpine> <void> .synd würde mit nichts kollidieren 16:44 <kostya213> auch gut 16:45 <vulpine> <void> verdammt, Lag :( 16:48 <jrandom> ok, springen wir rüber zu 3.2) Warum ist Syndie wichtig? 16:48 <vulpine> <void> jrandom: warte 16:48 <cervantes> (weil du sagst, dass es wichtig ist) 16:48 * jrandom wartet 16:48 <jrandom> !thwap cervantes ;) 16:48 <vulpine> <void> Im Status-Post steht, dass ein Avatar an einen Beitrag angehängt werden kann, andernfalls wird ein Standard verwendet 16:49 <vulpine> <void> aber was, wenn jemand mehrere vordefinierte Avatare statt eines einzigen „Standard“-Avatars haben möchte? 16:49 <jrandom> ja, der Autor kann einen Standard-Avatar in die Metadaten seines eigenen Channels aufnehmen 16:49 <vulpine> <void> jedes Mal den anderen anzuhängen, wird nicht effizient sein 16:49 <jrandom> Gute Frage, void – springen wir zu dem Skriptcode in den Notizen 16:50 <jrandom> listauthkeys --authorizedOnly true 16:50 <jrandom> authenticate 0 16:50 <vulpine> <void> (?) 16:50 <jrandom> listauthkeys zeigt alle Identitäten an, mit denen du die Nachricht so signieren kannst, dass du es bist, während „authenticate 0“ eine Identität zum Signieren auswählt 16:51 <jrandom> Diese Identität hat also ihren eigenen Channel, und dieser Channel hat eigene Metadaten, die einen Avatar enthalten können 16:51 <vulpine> <void> hmm, eine separate Identität bedeutet ein separates Schlüsselpaar? 16:51 <jrandom> ja 16:51 <vulpine> <void> was ist, wenn jemand mehrere Avatare zu einer einzigen Identität haben möchte? 16:52 <jrandom> Sie haben einen Standard-Avatar in ihren Channel-Metadaten, und sie können ihn pro Nachricht überschreiben 16:52 <kostya213> zweifelhafter Nutzen 16:52 <vulpine> <void> mehrere „Standard“-Avatare, aus denen er wählen kann 16:52 <vulpine> <void> oder spalte ich hier Haare? :) 16:53 <jrandom> ah, ich verstehe, was du meinst. Nee, wird anfangs nicht unterstützt 16:53 <jrandom> vielleicht später 16:53 <vulpine> <void> stimmt, kostya213, dann schon gut 16:53 <vulpine> <void> :) 16:53 <jrandom> (aber die Avatare werden in der Größe sehr begrenzt sein, daher sollte es nicht viel Mühe machen, sie einzubinden) 16:53 <vulpine> * Complication findet, dass das Hinzufügen pro Nachricht leicht genug zu codieren sein sollte 16:53 <vulpine> <void> also, 3.1) Was ist Syndie? 16:53 <vulpine> <Complication> (früher oder später) 16:54 <vulpine> * cervantes klebt die IRC-Server zusammen 16:54 <vulpine> <void> Complication: jrandom hat gerade gesagt, dass er das ohnehin tun wird :) 16:54 <jrandom> (pro Nachricht wird im Baseline-Fall möglich sein, es geht um die Idee, viele „Defaults“ zur Auswahl zu haben, und diese zu wählen, indem man in einer Nachricht „use avatar 1“ sagt, statt den Avatar selbst beizulegen) 16:54 <vulpine> <Complication> Latenz, Latenz... 16:54 <jrandom> ok, noch etwas zu 3.1? 16:54 <jrandom> wenn nicht, springen wir zu 3.2 16:55 <vulpine> <void> ich denke, das ist alles 16:55 <jrandom> wr0d. 16:56 <jrandom> abgesehen von cervantes' Spöttelei: Hat jemand Fragen/Kommentare/Bedenken zu „warum“? 16:56 <jrandom> (äh, „concerns“) 16:58 <vulpine> <Complication> cervantes: Hast du die Oberfläche mit Alkohol gereinigt, bevor du Kleber auf das ircd aufgetragen hast? ;) 16:58 <kostya213> Meiner Meinung nach braucht Syndie keine Rechtfertigung, sein Wert sollte für jeden, der sich bereits für anonymisierende Netzwerke interessiert, selbstevident sein 16:58 <kostya213> und sich der Gefahren der Zentralisierung von Information bewusst ist 16:59 <vulpine> <Complication> (Repost, bitte ignorieren, falls beim Server angekommen) 16:59 <vulpine> * Complication meint, dass Syndie wichtig ist, weil Joe Sixpack mit phpBB zu schnell gepwned würde, und Joe Sixpack mit $random_blogging_tool ebenso 16:59 <vulpine> <Complication> (auch wenn die Wahrscheinlichkeit variieren mag) 16:59 <vulpine> <void> in der Tat 16:59 <jrandom> ja, und jeder, der tatsächlichen feindseligen Gegnern gegenübersteht (nicht einmal unbedingt auf Staatsebene) 17:00 <jrandom> ok, cool, wollte das nur kurz mit euch durchgehen 17:00 <jrandom> noch etwas zu 3.2, oder gehen wir weiter zu 3.3) wann können wir Syndie nutzen? 17:01 <vulpine> <void> nun, im Wesentlichen ist es ein Forum-/Blog-/E-Mail-/Kommunikationstool, das auf kryptografischen Primitiven basiert und unabhängig von einer Transportschicht ist 17:01 <vulpine> <Complication> ...und im weiter hergeholten Szenario, dass Joe Sixpacks Gegner Schnittmengenangriffe startet, würde jeder, der irgendeine eepsite (I2P‑Webseite) betreibt, irgendwann gepwned werden (außer in einem riesigen Netzwerk) 17:01 <kostya213> Es ist vielleicht schwerer zu vermitteln für diejenigen, die keinen unmittelbaren Wert in Privatsphäre/Anonymität sehen 17:01 <jrandom> kostya213: ja, obwohl wir vielleicht ein paar Tricks nutzen können, wie z. B. sicheres Offline-Browsen 17:02 <vulpine> <Complication> Sie könnten Sicherheit trotzdem zu schätzen wissen 17:02 <jrandom> (z. B. ein Offline-RSS-Reader, der auch die vollständige Menge der referenzierten Seiten zieht, nicht nur die RSS-Zusammenfassung) 17:02 <vulpine> <void> also ja, ich sehe nicht, warum es Rechtfertigung braucht :) 17:02 <vulpine> <void> kostya213: sie müssen nicht anonym sein, um Syndie zu nutzen 17:02 <cervantes> wann können wir Syndie verwenden oder wann wird Syndie benutzbar sein? 17:02 <jrandom> word, void :) 17:03 <cervantes> für die Textschnittstelle stelle ich mir vor, dass es eine ziemlich umfangreiche Nutzungsdokumentation braucht 17:03 <jrandom> cervantes: im Moment ist Syndie funktionsfähig (man kann Beiträge erstellen, Channels verwalten, Beiträge lesen, auf Beiträge antworten usw.) 17:03 <kostya213> jrandom: Wie handhabt Syndie Redundanz? Wie widerstandsfähig ist es dagegen, dass Inhalte verschwinden? 17:03 <cervantes> (bevor es benutzbar ist) 17:03 <jrandom> cervantes: Es gibt Inline-Menüs mit jeweils dokumentiertem Befehl (zumindest minimal) 17:04 <cervantes> cool, irgendwelche Pläne für ein paar Use-Case-Beispiele? 17:04 <jrandom> kostya213: Syndie arbeitet auf der Inhaltsebene – Redundanz wird von etwas anderem gehandhabt. Wenn du zu Usenet postest, wird es über Usenet repliziert (zum Beispiel) 17:04 <cervantes> Ich denke, der Trick wird sein zu lernen, wie das alles zusammen skriptet 17:04 <vulpine> <void> kostya213: Das liegt außerhalb des Scopes von Syndie, es hängt vom Transportmechanismus ab 17:04 <vulpine> <void> leider 17:04 <jrandom> gute Idee, cervantes 17:05 <jrandom> Die erste Syndie-Version wird ein HTTP-Replikationssystem wie das alte/bestehende Syndie enthalten 17:05 <jrandom> cervantes: Vielleicht können einige der Beta-Nutzer ihre Lieblingsskripte zusammenstellen, damit wir sie verteilen :) 17:05 <modulus> mmm, ist das eine Konsolen-App? 17:05 <jrandom> modulus: ja, die erste textbasierte App 17:06 <modulus> ausgezeichnet! 17:06 <cervantes> jrandom: vorausgesetzt, die Beta-Nutzer bekommen heraus, wie man es benutzt ;-) 17:06 <jrandom> hehe 17:06 * jrandom hat curses/etc. sowie nur CLI erwogen, aber eine interaktive skriptbare Textschnittstelle ist wahrscheinlich das Einfachste und Nützlichste 17:07 <jrandom> (ohne GUI, wohlgemerkt) 17:07 <cervantes> modulus: siehst du, jrandom hat auf dein unermüdliches Feedback gehört :) 17:07 <vulpine> <Complication> Wenn Leute wollen, können sie vermutlich interaktivere Textoberflächen obendrauf bauen 17:07 <jrandom> ja, sicher 17:08 <jrandom> (der Code ist so gebaut, dass er eine einfache Integration mit einem IRC-Client wie pircbot unterstützt) 17:08 <modulus> cervantes: hehe 17:09 <modulus> Ich schätze, man könnte obendrein auch eine GUI draufsetzen, wenn es ungefähr so funktioniert, wie ich es mir vorstelle 17:09 <modulus> obwohl das deutlich mehr Arbeit wäre. 17:09 * kostya213 wartet auf das Emacs-Plugin 17:09 <modulus> hahaha 17:09 <jrandom> heh 17:09 <modulus> eigentlich ist ein Emacs-Mode gar keine schlechte Idee, vielleicht zieht das noch mehr Verrückte an. 17:10 <cervantes> drücke Strg-Alt-Umschalt-Pause-Pfeilhoch-Num7-b, um deine Identität zu wählen 17:10 * jrandom überlässt das den Elispers zum Durchhacken ;) 17:10 <kostya213> nichts für ungut, aber ich bin nicht sicher, dass dieses Projekt mehr Verrückte anziehen muss 17:10 <vulpine> <Complication> würden diese Art Verrückte auch Code schreiben? 17:11 <jrandom> hoffentlich, Complication 17:11 <jrandom> ok, hoffentlich erklärt 3.3) ein wenig, was als Nächstes kommt 17:11 <jrandom> Was das *wann* angeht – nun ja, wir werden sehen, aber ich hoffe auf „bald“ ;) 17:12 <jrandom> ok, hat noch jemand etwas zu 3.3)? 17:12 <vulpine> * Complication würde dann ein paar Horden dieser Verrückten begrüßen :D 17:12 <cervantes> Nun, es gibt Coden, und dann gibt es das Schreiben von verschleiertem Perl, das in Tcl interpretiert wird 17:12 <kostya213> Ein Plugin für FUSE könnte auch nützlich sein 17:13 <jrandom> ja 17:13 <jrandom> ok, springen wir rüber zu 4) Krypto für Syndie 17:13 <jrandom> hat jemand Kommentare zu diesen Themen? 17:14 <vulpine> <Complication> Wünschte ich hätte, aber ich bin nicht kompetent genug, um die Stärke dieser Chiffren/Hashes/Schlüssellängen zu beurteilen 17:15 <vulpine> <void> wie lang sind ElGamal/RSA-Signaturen? 4 kBit für einen 2-kBit-Schlüssel? 17:15 <vulpine> * Complication überlässt dieses Gespräch komplett anderen 17:15 <jrandom> weiß ich aus dem Stegreif nicht 17:15 <vulpine> <void> im Vergleich zu DSA? 17:16 <jrandom> (obwohl ECC schön klein aussieht) 17:16 <modulus> ElGamal-Signaturen sind schwierig und lang. Wie das GnuPG-Team herausgefunden hat. 17:16 <jrandom> ja, wobei einige dieser Tricks mit Schlüsselwiederverwendung zusammenhingen 17:16 <vulpine> <void> ah, ok 17:16 <vulpine> <void> ja, tut es 17:16 <tethra> modulus: Wenn sie hart und lang sind, gibt es dafür eine Fetisch-Seite 17:17 <jrandom> ok, der Punkt war wirklich nur ein Hinweis und eine Bitte um Kommentare, wann immer ihr Gedanken dazu habt 17:17 <cervantes> Wäre es nicht möglich, eine Art pluggable Ciphers zu implementieren – wenn eine bessere Methode zur Schlüsselerzeugung standardisiert ist, können wir die zu Syndie hinzufügen, und neue Beiträge beginnen, sie zu nutzen, aber für ältere Beiträge können noch veraltete Methoden verwendet werden 17:17 <tethra> (sorry) 17:17 <jrandom> cervantes: Es enthält ein DSA:-Präfix, also würde ein Elg:-Präfix funktionieren 17:17 <modulus> verwendet ihr 1024-begrenztes DSA oder nicht? 17:18 <modulus> außerdem welcher Hash? SHA1 oder höherwertige Revisionen? 17:18 <cervantes> du bist also im Grunde nur darauf bedacht, Syndie einen guten Start zu verschaffen 17:18 <jrandom> DSA ist nur 1024 Bit (es gibt DSA2-Vorschläge für länger, aber die sind noch nicht standardisiert) 17:18 <jrandom> und ja, DSA erfordert SHA1 17:18 <modulus> hmm, meines Wissens waren sie vor der Standardisierung ziemlich stark. 17:18 <kostya213> cervantes hat einen guten Punkt: Syndie-Inhalte in festen Ciphers zu haben, bietet geringe Vorwärtsgeheimnis; man weiß nie, wann ein Algo den Bach runtergeht 17:18 <modulus> aber ich verfolge den Prozess nicht nah genug, also hast du wahrscheinlich recht 17:19 <jrandom> kostya213: aber Wahlfreiheit ist schlecht für Krypto, daher sollten wir feste Werte haben, wo wir können 17:19 <jrandom> (schlecht wegen der Anonymität) 17:19 <vulpine> <void> wisst ihr, warum nicht mehr Leute/Protokolle ECC verwenden? Haben sie Angst vor mangelnder Forschung oder sorgen sie sich einfach um Kompatibilität? 17:19 <modulus> Patente. 17:20 <jrandom> Patente und FUD, aber auch einige Bedenken bei der Implementierung 17:20 <vulpine> <void> ah, richtig, modulus 17:20 <modulus> btw, gibt es einen guten Grund, DSA statt z. B. RSA-SHA512 zu nehmen? 17:20 <tethra> Patente und FUD und der Staat (oh je) 17:20 <modulus> will nicht nerven, denke nur daran, dass GPG beispielsweise diesen Weg gegangen ist, unter anderen. 17:20 <jrandom> Diese Option habe ich seit Jahren nicht geprüft, modulus 17:21 <modulus> Offensichtlich ist DSA ein Standard, was dafür spricht, aber die Schlüssel sind klein und die Hashes sind schwach. Nicht, dass ich denke, dass es am Ende das schwächste Glied sein wird ;-) 17:23 <cervantes> Ich würde keine „Wahlfreiheit“ vorschlagen – aber neue Versionen von Syndie würden zunehmend sichere (obligatorische) Ciphers mitbringen 17:23 <vulpine> <Complication> Etwas Spielraum in den Strukturen für zukünftige Änderungen zu lassen, scheint mir sinnvoll, unabhängig davon, welche aktuelle Krypto sich als die beste erweist 17:23 <jrandom> ja, wobei das den Rückfall auf schwächere/ältere Versionen impliziert, um zu interoperieren 17:23 <jrandom> aber ok, wir arbeiten uns da durch 17:24 <jrandom> ok, springen wir rüber zu 5) ??? 17:24 <jrandom> hat jemand noch etwas für das Treffen anzusprechen? 17:25 <cervantes> Nicht in der Lage zu sein, die neuesten Beiträge aus der Lieblingsquelle zu lesen, ist ein guter Anreiz, dafür zu sorgen, dass alle upgegradet bleiben 17:25 <jrandom> bis zu einem gewissen Grad 17:26 <cervantes> no=not 17:26 <jrandom> (ja, es ist ein Anreiz, aber Leute sind faul/nicht interessiert an „Software-Upgrade“ usw.) 17:27 <jrandom> s/people/some people/ 17:27 <cervantes> Ich schätze, das ist dann deren Problem 17:27 <jrandom> stimmt 17:27 <kostya213> Die I2P-Implementierung kann zumindest schmerzfreie Upgrades haben 17:28 <jrandom> sicher 17:28 <cervantes> zum Thema ??? – Entschuldigung für die IRC-Konnektivität – der ISP sollte einen seiner großen Netz-Carrier „so schnell wie möglich“ wiederherstellen 17:29 <jrandom> w3wt 17:29 <vulpine> <Complication> Zum Thema ??? könnte ich vielleicht hinzufügen, dass der zweite (umfangreichere) Teil der NTP-Modifikationen kurz vor der Funktionsfähigkeit steht, und ich hoffe, ihn bald zum Testen einchecken zu können 17:29 * cervantes nimmt eine Prise Salz 17:29 <kostya213> Was sind die kurzfristigen Pläne für die router-Entwicklung? Ist die Roadmap korrekt? 17:29 <jrandom> genial, Complication 17:29 <vulpine> <Complication> Das Ziel ist, NTP-Server anhand der Uhrenabweichungen der Peers zu hinterfragen 17:29 <jrandom> kostya213: Stabilisierung, bis Syndie draußen ist 17:30 <jrandom> (aus meiner Perspektive) 17:30 <vulpine> <Complication> (und vermeiden, potenziell verbindungsschädliche Maßnahmen zu ergreifen) 17:31 <cervantes> großartig 17:32 <jrandom> ok, noch etwas für das Treffen? 17:34 * jrandom leitet den Abschluss ein 17:34 * jrandom *baf*t das Treffen zu