add some more coding tasks to the volunteer page
Roger Dingledine

Roger Dingledine commited on 2007-03-06 20:45:31
Zeige 1 geänderte Dateien mit 29 Einfügungen und 19 Löschungen.

... ...
@@ -19,18 +19,6 @@ services. Get them to tell their friends.</li>
19 19
   security, let them know about us.</li>
20 20
 </ol>
21 21
 
22
-<a id="Bugs"></a>
23
-<h2><a class="anchor" href="#Bugs">Critical bugs</a></h2>
24
-<ol>
25
-<li>Tor servers are not stable on Windows XP currently,
26
-because we try to use hundreds of sockets, and the
27
-Windows kernel doesn't seem capable of handling this. <a
28
-href="http://wiki.noreply.org/noreply/TheOnionRouter/WindowsBufferProblems">Please
29
-help us solve this!</a> Probably the best solution is to teach libevent
30
-how to use overlapped IO rather than select() on Windows, and then adapt
31
-Tor to the new libevent interface.</li>
32
-</ol>
33
-
34 22
 <a id="Usability"></a>
35 23
 <h2><a class="anchor" href="#Usability">Supporting Applications</a></h2>
36 24
 <ol>
... ...
@@ -108,11 +96,38 @@ guidelines</a> if you want to help out. We also need people to help
108 96
 maintain the existing Italian, French, and Swedish translations -
109 97
 see the <a href="<page translation-status>">translation status
110 98
 overview</a>.</li>
99
+<li>Can somebody walk us through whether we want to go the
100
+<a href="http://www.cacert.org/">cacert</a> route for our
101
+SSL <a href="<page documentation>#Developers">SVN repository?</a></li>
111 102
 </ol>
112 103
 
113 104
 <a id="Coding"></a>
114 105
 <h2><a class="anchor" href="#Coding">Coding and Design</a></h2>
115 106
 <ol>
107
+<li>Tor servers don't work well on Windows XP. On
108
+Windows, Tor uses the standard <tt>select</tt> system
109
+call, which uses space in the non-page pool. This means
110
+that a medium sized Tor server will empty the non-page pool, <a
111
+href="http://wiki.noreply.org/noreply/TheOnionRouter/WindowsBufferProblems">causing
112
+havoc and crashes</a>. We should probably by using overlapped IO
113
+instead. One solution would be to teach libevent how to use overlapped IO
114
+rather than select() on Windows, and then adapt Tor to the new libevent
115
+interface.</li>
116
+<li>Because Tor servers need to store-and-forward each cell they handle,
117
+high-bandwidth Tor servers end up using dozens of megabytes of memory
118
+just for buffers. We need better heuristics for when to shrink/expand
119
+buffers. Maybe this should be modelled after the Linux kernel buffer
120
+design, where you have many smaller buffers that link to each other,
121
+rather than monolithic buffers?</li>
122
+<li>We need an official central site to answer "Is this IP address a Tor
123
+server?" questions. This should provide several interfaces, including
124
+a web interface and a DNSBL-style interface. It can provide the most
125
+up-to-date answers by keeping a local mirror of the Tor directory
126
+information. Bonus points if it does active testing through each exit
127
+node to find out what IP address it's really exiting from.</li>
128
+<li>We need a distributed testing framework. We have unit tests now,
129
+but it would be great to have a script that starts up a Tor network, uses
130
+it for a while, and verifies that at least parts of it are working.</li>
116 131
 <li>Right now the hidden service descriptors are being stored on just a
117 132
 few directory servers. This is bad for privacy and bad for robustness. To
118 133
 get more robustness, we're going to need to make hidden service
... ...
@@ -127,15 +142,10 @@ and signature on a hidden service descriptor so they can't be tricked
127 142
 into giving out fake ones. Second, any reliable distributed storage
128 143
 system will do, as long as it allows authenticated updates, but as far
129 144
 as we know no implemented DHT code supports authenticated updates.</li>
130
-<li>Tor 0.1.1.x includes support for hardware crypto accelerators via
145
+<li>Tor 0.1.1.x and later include support for hardware crypto accelerators
146
+via
131 147
 OpenSSL. Nobody has ever tested it, though. Does somebody want to get
132 148
 a card and let us know how it goes?</li>
133
-<li>Because Tor servers need to store-and-forward each cell they handle,
134
-high-bandwidth Tor servers end up using dozens of megabytes of memory
135
-just for buffers. We need better heuristics for when to shrink/expand
136
-buffers. Maybe this should be modelled after the Linux kernel buffer
137
-design, where you have many smaller buffers that link to each other,
138
-rather than monolithic buffers?</li>
139 149
 <li>Perform a security analysis of Tor with <a
140 150
 href="http://en.wikipedia.org/wiki/Fuzz_testing">"fuzz"</a>. Determine
141 151
 if there are good fuzzing libraries out there for what we want. Win fame by
142 152