[or-cvs] r13853: - translated volunteer page (removed many resolved issues) (website/trunk/de)
qbi at seul.org
qbi at seul.org
Tue Mar 4 11:39:25 UTC 2008
Author: qbi
Date: 2008-03-04 06:39:24 -0500 (Tue, 04 Mar 2008)
New Revision: 13853
Modified:
website/trunk/de/volunteer.wml
Log:
- translated volunteer page (removed many resolved issues)
Modified: website/trunk/de/volunteer.wml
===================================================================
--- website/trunk/de/volunteer.wml 2008-03-04 11:25:45 UTC (rev 13852)
+++ website/trunk/de/volunteer.wml 2008-03-04 11:39:24 UTC (rev 13853)
@@ -1,5 +1,5 @@
## translation metadata
-# Based-On-Revision: 11649
+# Based-On-Revision: 13843
# Last-Translator: jens at kubieziel.de, peter at palfrader.org
#include "head.wmi" TITLE="Mithelfen"
@@ -99,13 +99,6 @@
<h2><a class="anchor" href="#Documentation">Dokumentation</a></h2>
<ol>
- <li>Wir hören, dass Tornutzer diversen
- Attacken von Javascript, Java, ActiveX, Flash etc. zu Opfer
- fallen. Gibt es da draußen gute Plugins (wie NoScript für den
- Firefox), die es den Nutzern erleichtern, diese Risiken zu meistern?
- Was ist exakt das Risiko?</li>
- <li>Gibt es eine komplette Seite mit Plugins, welche die komplette
- Funktionalität von Privoxy für Firefox 1.5+ ersetzen?</li>
<li>Bitte hilf Matt Edman mit der Dokumentation und HOWTOs für
seinen <a href="http://vidalia-project.net/">Vidalia</a>.</li>
<li>Kommentiere und dokumentiere unsere <a
@@ -136,38 +129,15 @@
verwenden auf Windows den standardmäßigen <code>select</code>-Systemaufruf.
Dies bereitet gerade auf mittelgroßen Servern <a
href="https://wiki.torproject.org/noreply/TheOnionRouter/WindowsBufferProblems">Probleme</a>.
- Wahrscheinlich sollten wir hier besser Overlapped I/O nutzen. Eine Lösung ist,
- <a href="http://www.monkey.org/~provos/libevent/">libevent</a> beizubringen, Overlapped I/O statt <code>select()</code> zu wählen
- und Tor dann an die neue libevent-Schnittstelle anzupassen.</li>
- <li>Weil die Torserver jede Zelle speichern und weitergeben müssen,
- brauchen die Torserver mit hoher Bandbreite Dutzende Megabyte an
- Speicher. Wir benötigen bessere Heuristiken, wenn die Buffer zu
- verkleinern/vergrößern sind. Wahrscheinlich sollte dies nach dem
- Bufferdesign des Linuxkernels modelliert werden. Dort gibt es
- kleinere Buffer, die sich gegenseitig verbinden.</li>
- <li>Wir brauchen eine offizielle zentrale Seite, die die Frage "Ist das die
- Adresse eines Torservers" beantwortet. Es sollte diverse Schnittstelle, wie
- ein Webformular und DNSBL-ähnliche Abfrage, bieten. Es kann aktuelle
- Informationen bieten, indem es einen lokalen Spiegel der
- Verzeichnisinformationen anlegt. Du bekommst Bonuspunkte, wenn es aktiv
- die Exitserver testet, wie die IP-Adresse ist. Der schwierige Punkt ist, das
- die Eigenschaft, Exitserver zu sein, nicht einfach mit ja oder nein zu
- beantworten ist. Daher ist die Frage eher: "Ist diese IP-Adresse ein
- Exiterver, der mich zur IP-Adresse:Port weitergibt?". Die DNSBL-Schnittstelle
- wird wahrscheinlich Hunderte von Anfragen pro Minute bekommen. Daher sind hier
- intelligente Algorithmen gefragt. <a
- href="<svnsandbox>doc/contrib/torbl-design.txt">Hier</a> kannst du mehr dazu
- lesen.</li>
- <li>Manchmal stürzen Torserver ab oder die Computer, auf denen das Programm
- läuft, verschwinden vom Netz. Manche Betreiber von Tor haben Interesse
- geäußert, an einem Service teilzunehmen, der in regelmäßigen Abständen prüft,
- ob der jeweilige Torserver noch läuft und Mails versendet, falls das nicht der
- Fall ist. Eventuell möchte jemand ein paar CGI-Skripte und Webseiten schreiben
- and einen wget-hack oder etwas komplexeres wie <a
- href="http://nagios.org/">Nagios</a> für das Monitoring machen? Die erste
- Version sollte nur den Directoryport prüfen. Beispielsweise könnte das
- Programm durch die Netzwerkstatusseite nach der richtigen IP-Adresse sowie
- Port schauen und dann nach der "/tor/server/authority"-Seite.</li>
+ Wahrscheinlich sollten wir hier besser Overlapped I/O nutzen. Eine Lösung
+ wäre, <a href="http://www.monkey.org/~provos/libevent/">libevent</a>
+ beizubringen, Overlapped I/O statt <code>select()</code> zu wählen. Tor muss
+ dann an die neue libevent-Schnittstelle angepasst werden. Christian King hat
+ <a href="https://tor-svn.freehaven.net/svn/libevent-urz/trunk/">einen guten
+ Anfang</a> gemacht.</li>
+ <li>Wie können wir die <a
+ href="http://anonymityanywhere.com/incognito/">Incognito LiveCD</a> leichter
+ zu warten, verbessern und zu dokumentieren machen?</li>
<li>Wir brauchen ein verteiltes Testgerüst. Bisher haben wir Unittests. Es
wäre großartig, ein Skript zu haben, welches ein Tornetzwerk startet und dort
für einige Zeit testet, ob die Erneuerungen funktionieren.</li>
@@ -178,23 +148,6 @@
href="https://www.torproject.org/svn/torctl/doc/howto.txt">Tor Controller Protokoll
</a> nutzt, um mit Tor eine Vielzahl von Verbindungen zu schaffen, diese zu
messen und Anomalien festzustellen.</li>
- <li>Wir brauchen eine Messung von <a
- href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> und <a
- href="http://www.privoxy.org/">Privoxy</a>. Ist Polipo wirklich schneller,
- wenn man die Verlangsamung durch Tor mit einrechnet? Behandelt Polipo die
- Webseiten korrekter als Privoxy? Gibt es Probleme mit der Stabilität bei den
- häufig genutzten Plattformen?</li>
- <li>Es wäre großartig, wenn es eine Live-CD mit den aktuellsten Versionen von
- Tor, Polipo oder Privoxy, Firefox, Pidgin+OTR usw. gäbe. Es gibt hier zwei
- Herausforderungen: Zum einen muss das System dokumentiert werden und zum
- anderen müssen wir herausfinden, wie das leicht zu pflegen ist. Es sollte
- nicht so schnell obsolet werden, wie AnonymOS. Bonuspunkte gibt es, wenn die
- CD auf eine kleine CD (50MB) passt.</li>
- <li>In Bezug auf das CD-Image sollten wir auch an einer sicheren und gut
- dokumentierten USB-Variante für Tor und unterstützete Anwendungen arbeiten.
- Der schwierige Teil ist zu entscheiden, welche Konfigurationen sicher sind,
- diese Entscheidungen zu dokumentieren und etwas zu schaffen, das leicht zu
- pflegen ist.</li>
<li>Wir sollten damit anfangen unser <a href="<page
documentation>#DesignDoc">gegen Blockierungen geschütztes Design</a> zu
implementieren. Dies beinhaltet die Ausarbeitung des Designs, die
@@ -245,6 +198,9 @@
<li>Wir sind nicht weit davon entfernt, Unterstützung für IPv6 bei
Exitknoten zu haben. Falls du dich stark um IPv6 kümmerst, ist
das wahrscheinlich der Platz, um zu starten.</li>
+ <li>Du magst keinen von den obigen Punkten? Schaue dir die <a
+ href="<svnsandbox>doc/design-paper/roadmap-future.pdf">weiteren Pläne</a> für
+ weitere Ideen an.</li>
</ol>
<a id="Research"></a>
More information about the tor-commits
mailing list