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 |