Jacob Appelbaum commited on 2008-03-12 09:11:36
Zeige 1 geänderte Dateien mit 8 Einfügungen und 8 Löschungen.
... | ... |
@@ -196,7 +196,7 @@ as a daemon running as the debian-tor user and (sensibly) do not have a |
196 | 196 |
<a href="<svnsandbox>doc/spec/control-spec.txt">ControlPort</a> defined |
197 | 197 |
in the default torrc. Consequently, Vidalia will try |
198 | 198 |
to start its own Tor process since it could not connect to the existing |
199 |
-Tor, and then Vidalia's Tor process will then exit with an error message |
|
199 |
+Tor, and Vidalia's Tor process will then exit with an error message |
|
200 | 200 |
the user likely doesn't understand since Tor cannot bind its listening |
201 | 201 |
ports — they're already in use by the original Tor daemon. |
202 | 202 |
<br /> |
... | ... |
@@ -212,7 +212,7 @@ if the user running Vidalia is also in the debian-tor group. |
212 | 212 |
This project will first involve adding support for Tor's ControlSocket |
213 | 213 |
to Vidalia. The student will then develop and test Debian and Ubuntu |
214 | 214 |
packages for Vidalia that conform to Debian's packaging standards and |
215 |
-making sure it works well with the existing Tor packages. We can also |
|
215 |
+make sure they work well with the existing Tor packages. We can also |
|
216 | 216 |
set up an apt repository to host the new Vidalia packages. |
217 | 217 |
<br /> |
218 | 218 |
The next challenge would be to find an intuitive usable way for Vidalia |
... | ... |
@@ -266,8 +266,8 @@ the user. Of course, this is just an example and the student is free to |
266 | 266 |
suggest another approach. |
267 | 267 |
<br /> |
268 | 268 |
A student undertaking this project should have good UI design and layout |
269 |
-experience and some C++ development experience. Previous experience |
|
270 |
-with Qt and Qt's Designer will be very helpful, but not required. Some |
|
269 |
+and some C++ development experience. Previous experience with Qt and |
|
270 |
+Qt's Designer will be very helpful, but are not required. Some |
|
271 | 271 |
English writing ability will also be useful, since this project will |
272 | 272 |
likely involve writing small amounts of help documentation that should |
273 | 273 |
be understandable by non-technical users. Bonus points for some graphic |
... | ... |
@@ -317,7 +317,7 @@ Skill Level: <i>Low to Medium</i> |
317 | 317 |
Likely Mentors: <i>Jacob, Steven</i> |
318 | 318 |
<br /> |
319 | 319 |
We currently have a functional web page to detect if Tor is working. It |
320 |
-is has a few places where it falls short. It requires improvements with |
|
320 |
+has a few places where it falls short. It requires improvements with |
|
321 | 321 |
regard to default languages and functionality. It currently only responds |
322 | 322 |
in English. In addition, it is a hack of a perl script that should have |
323 | 323 |
never seen the light of day. It should probably be rewritten in python |
... | ... |
@@ -326,7 +326,7 @@ href="http://exitlist.torproject.org/">Tor DNS exit list</a> |
326 | 326 |
and should continue to do so in the future. It currently result in certain |
327 | 327 |
false positives and these should be discovered, documented, and fixed |
328 | 328 |
where possible. Anyone working on this project should be interested in |
329 |
-DNS, basic perl or preferably python programming skills and will have |
|
329 |
+DNS, basic perl or preferably python programming skills, and will have |
|
330 | 330 |
to interact minimally with Tor to test their code. |
331 | 331 |
<br /> |
332 | 332 |
If you want to make the project more exciting |
... | ... |
@@ -887,7 +887,7 @@ href="http://www.monkey.org/~provos/libevent/">libevent</a> how to use |
887 | 887 |
overlapped IO rather than select() on Windows, and then adapt Tor to |
888 | 888 |
the new libevent interface. Christian King made a |
889 | 889 |
<a href="https://tor-svn.freehaven.net/svn/libevent-urz/trunk/">good |
890 |
-start</a> on this last summer.</li> |
|
890 |
+start</a> on this in the summer of 2007.</li> |
|
891 | 891 |
<li>We need to actually start building our <a href="<page |
892 | 892 |
documentation>#DesignDoc">blocking-resistance design</a>. This involves |
893 | 893 |
fleshing out the design, modifying many different pieces of Tor, adapting |
... | ... |
@@ -993,7 +993,7 @@ few KB/s of traffic into the Tor network. (A few KB/s shouldn't be too |
993 | 993 |
much hassle, and there are few abuse issues since they're not being exit |
994 | 994 |
nodes.) But how do we distribute a list of these volunteer clients to the |
995 | 995 |
good dissidents in an automated way that doesn't let the country-level |
996 |
-firewalls intercept and enumerate them? Probably needs to work on a |
|
996 |
+firewalls intercept and enumerate them? This probably needs to work on a |
|
997 | 997 |
human-trust level. See our <a href="<page documentation>#DesignDoc">early |
998 | 998 |
blocking-resistance design document</a> and our |
999 | 999 |
<a |
1000 | 1000 |