Jan Reister commited on 2008-03-12 15:40:43
Zeige 1 geänderte Dateien mit 793 Einfügungen und 24 Löschungen.
... | ... |
@@ -1,5 +1,5 @@ |
1 | 1 |
## translation metadata |
2 |
-# Based-On-Revision: 13843 |
|
2 |
+# Based-On-Revision: 13989 |
|
3 | 3 |
# Last-Translator: jan at seul dot org |
4 | 4 |
|
5 | 5 |
#include "head.wmi" TITLE="Tor: partecipa" CHARSET="UTF-8" |
... | ... |
@@ -23,7 +23,7 @@ comunicazioni, fagli conoscere il progetto Tor.</li> |
23 | 23 |
<a id="Usability"></a> |
24 | 24 |
<h2><a class="anchor" href="#Usability">Applicazioni di supporto</a></h2> |
25 | 25 |
<ol> |
26 |
-<li>Serve un buon sistema per intercetare le richieste DNS in modo che non siano svelate |
|
26 |
+<li>Servono altri buoni metodi per intercettare le richieste DNS in modo che non siano svelate |
|
27 | 27 |
a un osservatore locale mentre cerchiamo di essere anonimi. (Ciò |
28 | 28 |
succede se l'applicazione esegue la risoluzione DNS prima di rivolgersi |
29 | 29 |
al proxy SOCKS.)</li> |
... | ... |
@@ -92,6 +92,794 @@ Serve anche aiuto per correggere e migliorare questa traduzione italiana.</li> |
92 | 92 |
</ol> |
93 | 93 |
|
94 | 94 |
<a id="Coding"></a> |
95 |
+<a id="Summer"></a> |
|
96 |
+<a id="Projects"></a> |
|
97 |
+<h2><a class="anchor" href="#Projects">Progetti di siluppo software</a></h2> |
|
98 |
+ |
|
99 |
+<p> |
|
100 |
+Alcuni di questi progetti potrebbero essere dei buoni candidati per <a href="<page |
|
101 |
++gsoc>">Google Summer of Code 2008</a>. Abbiamo classificato ogni idea |
|
102 |
+secondo l'utilità complessiva al progetto Tor |
|
103 |
+(priorità), quanto lavoro stimiamo sia necessario (livello d'impegno), quante |
|
104 |
+conoscenze servono per iniziare (livello di competenze), e quali dei nostri <a href="<page |
|
105 |
++people>#Core">principali programmatori</a> potrebbero essere dei buoni mentori. |
|
106 |
+</p> |
|
107 |
+<p> |
|
108 |
+(NdT: Le schede di alcuni progetti sono in inglese e verranno tradotte man mano.) |
|
109 |
+</p> |
|
110 |
+<ol> |
|
111 |
+ |
|
112 |
+<li> |
|
113 |
+<b>Framework per l'aggiornamento automatico di Tor/Polipo/Vidalia Framework</b> |
|
114 |
+<br /> |
|
115 |
+Priorità: <i>Alta</i> |
|
116 |
+<br /> |
|
117 |
+Impegno: <i>Alto</i> |
|
118 |
+<br /> |
|
119 |
+Competenze: <i>Alte</i> |
|
120 |
+<br /> |
|
121 |
+Possibili mentori: <i>Matt, Jacob</i> |
|
122 |
+<br /> |
|
123 |
+Ci seve un buon framework per l'aggiornamento autenticato. |
|
124 |
+Vidalia si accorge già se l'utente ha una versione obsoleta |
|
125 |
+o deprecata di Tor, tramite dei signed statement nelle informazioni |
|
126 |
+di directory Tor. Al momento Vidalia manda una semplice |
|
127 |
+finestra di avviso che informa l'utente che dovrebbe aggiornare manualmente. |
|
128 |
+Lo scopo del progetto è di estendere Vidalia aggiungendo la |
|
129 |
+possibilità di scaricare e installare il software Tor aggiornato al |
|
130 |
+posto dell'utente. Il download dovrebbe avenire via Tor quando possibile, con un buon |
|
131 |
+meccanismo di fall back al download diretto. Tempo permettendo sarebbe bello |
|
132 |
+potere aggiornare altre applicazioni |
|
133 |
+contenute nei pacchetti di installazione, come Polipo e |
|
134 |
+Vidalia stessa. |
|
135 |
+<br /> |
|
136 |
+Per portare a termine il progetto, lo studente dovrà anzitutto studiare |
|
137 |
+il framework di auto-update esistente (ad es., Sparkle su OS X) per valutarne |
|
138 |
+vantaggi, debolezze, fattori di sicurezza e possibilità di venire |
|
139 |
+integrato in Vidalia. Se non se ne trovano di adatti, lo studente |
|
140 |
+disegnerà uno proprio frameword di auto aggiornamento, documentando il disegno e |
|
141 |
+discutendolo con altri sviluppatori per verificarne gli aspetti di sicurezza. |
|
142 |
+Lo studente realizzerà poi il framework (o lo integrerà con |
|
143 |
+uno esistente) e lo sottoporr6agrave; a test. |
|
144 |
+<br /> |
|
145 |
+Gli studenti interessati a questo progetto devono avere una buona esperienza di sviluppo |
|
146 |
+in C++. Utili, ma non obbligatorie, esperienze di Qt. Occorre anche |
|
147 |
+una buona comprensione delle comuni pratiche di sicurezza, |
|
148 |
+come la package signature verification. Importanti per il progetto anche buone |
|
149 |
+capacità di comunicazione scritta, poiché una fase cruciale |
|
150 |
+sarà la produzione di un design document che altri valuteranno e discuteranno |
|
151 |
+con lo studente prima della realizzazione. |
|
152 |
+</li> |
|
153 |
+ |
|
154 |
+<li> |
|
155 |
+<b>Una Network Map per Vidalia migliore e più usabile</b> |
|
156 |
+<br /> |
|
157 |
+Priorità: <i>Media</i> |
|
158 |
+<br /> |
|
159 |
+Impegno: <i>Medio</i> |
|
160 |
+<br /> |
|
161 |
+Competenze: <i>Medio-alte</i> |
|
162 |
+<br /> |
|
163 |
+Possibili mentori: <i>Matt</i> |
|
164 |
+<br /> |
|
165 |
+Vidalia ha una carta della rete che mostra all'utente la posizione |
|
166 |
+geografica approssimata dei nodi nella rete Tor e che |
|
167 |
+disegna il percorso del traffico dell'utente attraverso i tunnel stabiliti nella |
|
168 |
+rete Tor. The mappa per ora non è molto interattiva ed ha una grafica |
|
169 |
+spartana. Ci piacerebbe usare il widget KDE Marble che |
|
170 |
+crea mappe di miglior qualità ed offre maggior einterattività, |
|
171 |
+permettendo all'utente di fare clic su singoli nodi o circuiti per ottenere |
|
172 |
+maggiori informazioni. Potremmo anche permettere all'utente di fare |
|
173 |
+clic su un particolare nodo o su un paese contenente uno o più |
|
174 |
+Tor exit relay e dire, ad esempio: "Voglio che le mie connessioni a pippo.com |
|
175 |
+escano da qui." |
|
176 |
+<br /> |
|
177 |
+Questo progetto richiede anzitutto che lo studente si familiarizzi con Vidalia |
|
178 |
+e le API del widget Marble. Lo studente integrerà poi il widget |
|
179 |
+in Vidalia e personalizzerà Marble per adattarlo meglio ai nostri bisogni, |
|
180 |
+ad esempio rendendo cliccabili i circuiti, memorizzando i dati di cache nella |
|
181 |
+data directory di Vidalia, e personalizzando alcuni messaggi di dialogo del widget. |
|
182 |
+<br /> |
|
183 |
+Gli studenti impegnati in questo progettp devono avere una buona esperienza |
|
184 |
+di sviluppo C++. Utile, ma non obbligatorio, avere avuto esperienza con Qt e |
|
185 |
+Cmake. |
|
186 |
+</li> |
|
187 |
+ |
|
188 |
+<li> |
|
189 |
+<b>Better Debian Packaging for Tor+Vidalia</b> |
|
190 |
+<br /> |
|
191 |
+Priority: <i>High</i> |
|
192 |
+<br /> |
|
193 |
+Effort Level: <i>Medium</i> |
|
194 |
+<br /> |
|
195 |
+Skill Level: <i>Medium</i> |
|
196 |
+<br /> |
|
197 |
+Likely Mentors: <i>Peter, Matt</i> |
|
198 |
+<br /> |
|
199 |
+Vidalia currently doesn't play nicely on Debian and Ubuntu with the |
|
200 |
+default Tor packages. The current Tor packages automatically start Tor |
|
201 |
+as a daemon running as the debian-tor user and (sensibly) do not have a |
|
202 |
+<a href="<svnsandbox>doc/spec/control-spec.txt">ControlPort</a> defined |
|
203 |
+in the default torrc. Consequently, Vidalia will try |
|
204 |
+to start its own Tor process since it could not connect to the existing |
|
205 |
+Tor, and Vidalia's Tor process will then exit with an error message |
|
206 |
+the user likely doesn't understand since Tor cannot bind its listening |
|
207 |
+ports — they're already in use by the original Tor daemon. |
|
208 |
+<br /> |
|
209 |
+The current solution involves either telling the user to stop the |
|
210 |
+existing Tor daemon and let Vidalia start its own Tor process, or |
|
211 |
+explaining to the user how to set a control port and password in their |
|
212 |
+torrc. A better solution on Debian would be to use Tor's ControlSocket, |
|
213 |
+which allows Vidalia to talk to Tor via a Unix domain socket, and could |
|
214 |
+possibly be enabled by default in Tor's Debian packages. Vidalia can |
|
215 |
+then authenticate to Tor using filesystem-based (cookie) authentication |
|
216 |
+if the user running Vidalia is also in the debian-tor group. |
|
217 |
+<br /> |
|
218 |
+This project will first involve adding support for Tor's ControlSocket |
|
219 |
+to Vidalia. The student will then develop and test Debian and Ubuntu |
|
220 |
+packages for Vidalia that conform to Debian's packaging standards and |
|
221 |
+make sure they work well with the existing Tor packages. We can also |
|
222 |
+set up an apt repository to host the new Vidalia packages. |
|
223 |
+<br /> |
|
224 |
+The next challenge would be to find an intuitive usable way for Vidalia |
|
225 |
+to be able to change Tor's configuration (torrc) even though it is |
|
226 |
+located in <code>/etc/tor/torrc</code> and thus immutable. The best |
|
227 |
+idea we've come up with so far is to feed Tor a new configuration via |
|
228 |
+the ControlSocket when Vidalia starts, but that's bad because Tor starts |
|
229 |
+each boot with a different configuration than the user wants. The second |
|
230 |
+best idea |
|
231 |
+we've come up with is for Vidalia to write out a temporary torrc file |
|
232 |
+and ask the user to manually move it to <code>/etc/tor/torrc</code>, |
|
233 |
+but that's bad because users shouldn't have to mess with files directly. |
|
234 |
+<br /> |
|
235 |
+A student undertaking this project should have prior knowledge of |
|
236 |
+Debian package management and some C++ development experience. Previous |
|
237 |
+experience with Qt is helpful, but not required. |
|
238 |
+</li> |
|
239 |
+ |
|
240 |
+<li> |
|
241 |
+<b>Tor Controller Status Event Interface</b> |
|
242 |
+<br /> |
|
243 |
+Priority: <i>Medium</i> |
|
244 |
+<br /> |
|
245 |
+Effort Level: <i>Medium</i> |
|
246 |
+<br /> |
|
247 |
+Skill Level: <i>Medium</i> |
|
248 |
+<br /> |
|
249 |
+Likely Mentors: <i>Matt, Roger</i> |
|
250 |
+<br /> |
|
251 |
+There are a number of status changes inside Tor of which the user may need |
|
252 |
+to be informed. For example, if the user is trying to set up his Tor as a |
|
253 |
+relay and Tor decides that its ports are not reachable from outside |
|
254 |
+the user's network, we should alert the user. Currently, all the user |
|
255 |
+gets is a couple log messages in Vidalia's 'message log' window, which they |
|
256 |
+likely never see since they don't receive a notification that something |
|
257 |
+has gone wrong. Even if the user does actually look at the message log, |
|
258 |
+most of the messages make little sense to the novice user. |
|
259 |
+<br /> |
|
260 |
+Tor has the ability to inform Vidalia of many such status changes, and |
|
261 |
+we recently implemented support for a couple of these events. Still, |
|
262 |
+there are many more status events the user should be informed of and we |
|
263 |
+need a better UI for actually displaying them to the user. |
|
264 |
+<br /> |
|
265 |
+The goal of this project then is to design and implement a UI for |
|
266 |
+displaying Tor status events to the user. For example, we might put a |
|
267 |
+little badge on Vidalia's tray icon that alerts the user to new status |
|
268 |
+events they should look at. Double-clicking the icon could bring up a |
|
269 |
+dialog that summarizes recent status events in simple terms and maybe |
|
270 |
+suggests a remedy for any negative events if they can be corrected by |
|
271 |
+the user. Of course, this is just an example and the student is free to |
|
272 |
+suggest another approach. |
|
273 |
+<br /> |
|
274 |
+A student undertaking this project should have good UI design and layout |
|
275 |
+and some C++ development experience. Previous experience with Qt and |
|
276 |
+Qt's Designer will be very helpful, but are not required. Some |
|
277 |
+English writing ability will also be useful, since this project will |
|
278 |
+likely involve writing small amounts of help documentation that should |
|
279 |
+be understandable by non-technical users. Bonus points for some graphic |
|
280 |
+design/Photoshop fu, since we might want/need some shiny new icons too. |
|
281 |
+</li> |
|
282 |
+ |
|
283 |
+<li> |
|
284 |
+<b>Translation Wiki</b> |
|
285 |
+<br /> |
|
286 |
+Priority: <i>High</i> |
|
287 |
+<br /> |
|
288 |
+Effort Level: <i>Medium</i> |
|
289 |
+<br /> |
|
290 |
+Skill Level: <i>Medium</i> |
|
291 |
+<br /> |
|
292 |
+Likely Mentors: <i>Jacob</i> |
|
293 |
+<br /> |
|
294 |
+We need a way to edit and translate sections of the website. Currently |
|
295 |
+the website is made up of a bunch of <a href="<svnsandbox>website/en/">wml |
|
296 |
+files</a>, and <a href="<page translation>">translators</a> fetch these |
|
297 |
+wml files, translate them in an editor, and either send us the translation |
|
298 |
+or use svn to commit them back. The current "cost" of publication of |
|
299 |
+website changes is quite high even for English language users. For a |
|
300 |
+single word change or any type of |
|
301 |
+minor change, the page may never be corrected or translated. It would |
|
302 |
+be nice to have a wiki that was specifically geared towards translation |
|
303 |
+and would somehow track the upstream (English) versions to indicate when |
|
304 |
+a fresh translation is needed, like our current |
|
305 |
+<a href="<page translation-status>">translation status page</a>. This |
|
306 |
+seems mostly like a job for a wiki |
|
307 |
+integrator or wiki software author. Certainly the person would need to |
|
308 |
+be interested in human languages and translation. They should at least |
|
309 |
+be minimally familiar with what Tor is; but they would not have to interact |
|
310 |
+with the software, only the documentation and the website. |
|
311 |
+</li> |
|
312 |
+ |
|
313 |
+<li> |
|
314 |
+<b>Improvements on our active browser configuration tester</b> - |
|
315 |
+<a href="https://check.torproject.org/">https://check.torproject.org/</a> |
|
316 |
+<br /> |
|
317 |
+Priority: <i>Medium</i> |
|
318 |
+<br /> |
|
319 |
+Effort Level: <i>Low</i> |
|
320 |
+<br /> |
|
321 |
+Skill Level: <i>Low to Medium</i> |
|
322 |
+<br /> |
|
323 |
+Likely Mentors: <i>Jacob, Steven</i> |
|
324 |
+<br /> |
|
325 |
+We currently have a functional web page to detect if Tor is working. It |
|
326 |
+has a few places where it falls short. It requires improvements with |
|
327 |
+regard to default languages and functionality. It currently only responds |
|
328 |
+in English. In addition, it is a hack of a perl script that should have |
|
329 |
+never seen the light of day. It should probably be rewritten in python |
|
330 |
+with multi-lingual support in mind. It currently uses the <a |
|
331 |
+href="http://exitlist.torproject.org/">Tor DNS exit list</a> |
|
332 |
+and should continue to do so in the future. It currently result in certain |
|
333 |
+false positives and these should be discovered, documented, and fixed |
|
334 |
+where possible. Anyone working on this project should be interested in |
|
335 |
+DNS, basic perl or preferably python programming skills, and will have |
|
336 |
+to interact minimally with Tor to test their code. |
|
337 |
+<br /> |
|
338 |
+If you want to make the project more exciting |
|
339 |
+and involve more design and coding, take a look at <a |
|
340 |
+href="<svnsandbox>doc/spec/proposals/131-verify-tor-usage.txt">proposal |
|
341 |
+131-verify-tor-usage.txt</a>. |
|
342 |
+</li> |
|
343 |
+ |
|
344 |
+<li> |
|
345 |
+<b>Improvements on our DNS Exit List service</b> - |
|
346 |
+<a href="http://exitlist.torproject.org/">http://exitlist.torproject.org/</a> |
|
347 |
+<br /> |
|
348 |
+Priority: <i>Medium</i> |
|
349 |
+<br /> |
|
350 |
+Effort Level: <i>Low</i> |
|
351 |
+<br /> |
|
352 |
+Skill Level: <i>Low</i> |
|
353 |
+<br /> |
|
354 |
+Likely Mentors: <i>Jacob, Tup</i> |
|
355 |
+<br /> |
|
356 |
+The <a href="http://p56soo2ibjkx23xo.onion/">exitlist software</a> |
|
357 |
+is written by our fabulous anonymous |
|
358 |
+contributer Tup. It's a DNS server written in Haskell that supports part of our <a |
|
359 |
+href="https://www.torproject.org/svn/trunk/doc/contrib/torel-design.txt">exitlist |
|
360 |
+design document</a>. Currently, it is functional and it is used by |
|
361 |
+check.torproject.org and other users. The issues that are outstanding |
|
362 |
+are mostly aesthetic. This wonderful service could use a much better |
|
363 |
+website using the common Tor theme. It would be best served with better |
|
364 |
+documentation for common services that use an RBL. It could use more |
|
365 |
+publicity. A person working on this project should be interested in DNS, |
|
366 |
+basic RBL configuration for popular services, and writing documentation. |
|
367 |
+The person would require minimal Tor interaction — testing their |
|
368 |
+own documentation at the very least. Furthermore, it would be useful |
|
369 |
+if they were interested in Haskell and wanted to implement more of the |
|
370 |
+torel-design.txt suggestions. |
|
371 |
+</li> |
|
372 |
+ |
|
373 |
+<li> |
|
374 |
+<b>Testing integration of Tor with web browsers for our end users</b> |
|
375 |
+<br /> |
|
376 |
+Priority: <i>Medium</i> |
|
377 |
+<br /> |
|
378 |
+Effort Level: <i>Medium</i> |
|
379 |
+<br /> |
|
380 |
+Skill Level: <i>Medium</i> |
|
381 |
+<br /> |
|
382 |
+Likely Mentors: <i>Jacob, Mike, Greg</i> |
|
383 |
+<br /> |
|
384 |
+The Tor project currently lacks a solid test suite to ensure that a |
|
385 |
+user has a properly and safely configured web browser. It should test for as |
|
386 |
+many known issues as possible. It should attempt to decloak the |
|
387 |
+user in any way possible. Two current webpages that track these |
|
388 |
+kinds of issues are run by Greg Fleischer and HD Moore. Greg keeps a nice <a |
|
389 |
+href="http://pseudo-flaw.net/tor/torbutton/">list of issues along |
|
390 |
+with their proof of concept code, bug issues, etc</a>. HD Moore runs |
|
391 |
+the <a href="http://metasploit.com/research/projects/decloak/">metasploit |
|
392 |
+decloak website</a>. A student interested in defending Tor could start |
|
393 |
+by collecting as many workable and known methods for decloaking a |
|
394 |
+Tor user. (<a href="https://torcheck.xenobite.eu/">This page</a> may |
|
395 |
+be helpful as a start.) The student should be familiar with the common |
|
396 |
+pitfalls but |
|
397 |
+possibly have new methods in mind for implementing decloaking issues. The |
|
398 |
+website should ensure that it tells a user what their problem is. It |
|
399 |
+should help them to fix the problem or direct them to the proper support |
|
400 |
+channels. The student should be closely familiar with using Tor and how |
|
401 |
+to prevent Tor information leakage. |
|
402 |
+</li> |
|
403 |
+ |
|
404 |
+<li> |
|
405 |
+<b>Improving Tor's ability to resist censorship</b> |
|
406 |
+<br /> |
|
407 |
+Priority: <i>High</i> |
|
408 |
+<br /> |
|
409 |
+Effort Level: <i>High</i> |
|
410 |
+<br /> |
|
411 |
+Skill Level: <i>High</i> |
|
412 |
+<br /> |
|
413 |
+Likely Mentors: <i>Nick</i> |
|
414 |
+<br /> |
|
415 |
+The Tor 0.2.0.x series makes <a |
|
416 |
+href="<svnsandbox>doc/design-paper/blocking.html">significant |
|
417 |
+improvements</a> in resisting national and organizational censorship. |
|
418 |
+But Tor still needs better mechanisms for some parts of its |
|
419 |
+anti-censorship design. For example, current Tors can only listen on a |
|
420 |
+single address/port combination at a time. There's |
|
421 |
+<a href="<svnsandbox>doc/spec/proposals/118-multiple-orports.txt">a |
|
422 |
+proposal to address this limitation</a> and allow clients to connect |
|
423 |
+to any given Tor on multiple addresses and ports, but it needs more |
|
424 |
+work. Another anti-censorship project (far more difficult) is to try |
|
425 |
+to make Tor more scanning-resistant. Right now, an adversary can identify |
|
426 |
+<a href="<svnsandbox>doc/spec/proposals/125-bridges.txt">Tor bridges</a> |
|
427 |
+just by trying to connect to them, following the Tor protocol, and |
|
428 |
+seeing if they respond. To solve this, bridges could |
|
429 |
+<a href="<svnsandbox>doc/design-paper/blocking.html#tth_sEc9.3">act like |
|
430 |
+webservers</a> (HTTP or HTTPS) when contacted by port-scanning tools, |
|
431 |
+and not act like bridges until the user provides a bridge-specific key. |
|
432 |
+<br /> |
|
433 |
+This project involves a lot of research and design. One of the big |
|
434 |
+challenges will be identifying and crafting approaches that can still |
|
435 |
+resist an adversary even after the adversary knows the design, and |
|
436 |
+then trading off censorship resistance with usability and robustness. |
|
437 |
+</li> |
|
438 |
+ |
|
439 |
+<li> |
|
440 |
+<b>Libevent and Tor integration improvements</b> |
|
441 |
+<br /> |
|
442 |
+Priority: <i>Medium</i> |
|
443 |
+<br /> |
|
444 |
+Effort Level: <i>High</i> |
|
445 |
+<br /> |
|
446 |
+Skill Level: <i>Medium to High</i> |
|
447 |
+<br /> |
|
448 |
+Likely Mentors: <i>Nick</i> |
|
449 |
+<br /> |
|
450 |
+Tor should make better use of the more recent features of Niels |
|
451 |
+Provos's <a href="http://monkey.org/~provos/libevent/">Libevent</a> |
|
452 |
+library. Tor already uses Libevent for its low-level asynchronous IO |
|
453 |
+calls, and could also use Libevent's increasingly good implementations |
|
454 |
+of network buffers and of HTTP. This wouldn't be simply a matter of |
|
455 |
+replacing Tor's internal calls with calls to Libevent: instead, we'll |
|
456 |
+need to refactor Tor to use Libevent calls that do not follow the |
|
457 |
+same models as Tor's existing backends. Also, we'll need to add |
|
458 |
+missing functionality to Libevent as needed — most difficult likely |
|
459 |
+will be adding OpenSSL support on top of Libevent's buffer abstraction. |
|
460 |
+Also tricky will be adding rate-limiting to Libevent. |
|
461 |
+</li> |
|
462 |
+ |
|
463 |
+<li> |
|
464 |
+<b>Tuneup Tor!</b> |
|
465 |
+<br /> |
|
466 |
+Priority: <i>Medium</i> |
|
467 |
+<br /> |
|
468 |
+Effort Level: <i>Medium</i> |
|
469 |
+<br /> |
|
470 |
+Skill Level: <i>Medium to High</i> |
|
471 |
+<br /> |
|
472 |
+Likely Mentors: <i>Nick, Roger, Mike</i> |
|
473 |
+<br /> |
|
474 |
+Right now, Tor relays measure and report their own bandwidth, and Tor |
|
475 |
+clients choose which relays to use in part based on that bandwidth. |
|
476 |
+This approach is vulnerable to |
|
477 |
+<a href="http://freehaven.net/anonbib/#bauer:wpes2007">attacks where |
|
478 |
+relays lie about their bandwidth</a>; |
|
479 |
+to address this, Tor currently caps the maximum bandwidth |
|
480 |
+it's willing to believe any relay provides. This is a limited fix, and |
|
481 |
+a waste of bandwidth capacity to boot. Instead, |
|
482 |
+Tor should possibly measure bandwidth in a more distributed way, perhaps |
|
483 |
+as described in the |
|
484 |
+<a href="http://freehaven.net/anonbib/author.html#snader08">"A Tune-up for |
|
485 |
+Tor"</a> paper |
|
486 |
+by Snader and Borisov. A student could use current testing code to |
|
487 |
+double-check this paper's findings and verify the extent to which they |
|
488 |
+dovetail with Tor as deployed in the wild, and determine good ways to |
|
489 |
+incorporate them into their suggestions Tor network without adding too |
|
490 |
+much communications overhead between relays and directory |
|
491 |
+authorities. |
|
492 |
+</li> |
|
493 |
+ |
|
494 |
+<!-- |
|
495 |
+<li> |
|
496 |
+<b>Improving the Tor QA process: Continuous Integration for Windows builds</b> |
|
497 |
+<br /> |
|
498 |
+Priority: <i>High</i> |
|
499 |
+<br /> |
|
500 |
+Effort Level: <i>Medium</i> |
|
501 |
+<br /> |
|
502 |
+Skill Level: <i>Medium</i> |
|
503 |
+<br /> |
|
504 |
+Likely Mentors: <i>Jacob, Andrew</i> |
|
505 |
+<br /> |
|
506 |
+It would be useful to have automated build processes for Windows and |
|
507 |
+probably other platforms. The purpose of having a continuous integration |
|
508 |
+build environment is to ensure that Windows isn't left behind for any of |
|
509 |
+the software projects used in the Tor project or its accompanying.<br /> |
|
510 |
+Buildbot may be a good choice for this as it appears to support all of |
|
511 |
+the platforms Tor does. See the |
|
512 |
+<a href="http://en.wikipedia.org/wiki/BuildBot">wikipedia entry for |
|
513 |
+buildbot</a>.<br /> |
|
514 |
+There may be better options and the person undertaking this task should |
|
515 |
+evaluate other options. Any person working on this automatic build |
|
516 |
+process should have experience or be willing to learn how to build all |
|
517 |
+of the respective Tor related code bases from scratch. Furthermore, the |
|
518 |
+person should have some experience building software in Windows |
|
519 |
+environments as this is the target audience we want to ensure we do not |
|
520 |
+leave behind. It would require close work with the Tor source code but |
|
521 |
+probably only in the form of building, not authoring.<br /> |
|
522 |
+Additionally, we need to automate our performance testing for all platforms. |
|
523 |
+We've got buildbot (except on Windows — as noted above) to automate |
|
524 |
+our regular integration and compile testing already, |
|
525 |
+but we need to get our network simulation tests (as built in torflow) |
|
526 |
+updated for more recent versions of Tor, and designed to launch a test |
|
527 |
+network either on a single machine, or across several, so we can test |
|
528 |
+changes in performance on machines in different roles automatically. |
|
529 |
+</li> |
|
530 |
+--> |
|
531 |
+ |
|
532 |
+<li> |
|
533 |
+<b>Improve our unit testing process</b> |
|
534 |
+<br /> |
|
535 |
+Priority: <i>Medium</i> |
|
536 |
+<br /> |
|
537 |
+Effort Level: <i>Medium</i> |
|
538 |
+<br /> |
|
539 |
+Skill Level: <i>Medium</i> |
|
540 |
+<br /> |
|
541 |
+Likely Mentors: <i>Nick</i> |
|
542 |
+<br /> |
|
543 |
+Tor needs to be far more tested. This is a multi-part effort. To start |
|
544 |
+with, our unit test coverage should rise substantially, especially in |
|
545 |
+the areas outside the utility functions. This will require significant |
|
546 |
+refactoring of some parts of Tor, in order to dissociate as much logic |
|
547 |
+as possible from globals. |
|
548 |
+<br /> |
|
549 |
+Additionally, we need to automate our performance testing. We've got |
|
550 |
+buildbot to automate our regular integration and compile testing already |
|
551 |
+(though we need somebody to set it up on Windows), |
|
552 |
+but we need to get our network simulation tests (as built in TorFlow: see |
|
553 |
+the "Tor Node Scanner improvements" item) |
|
554 |
+updated for more recent versions of Tor, and designed to launch a test |
|
555 |
+network either on a single machine, or across several, so we can test |
|
556 |
+changes in performance on machines in different roles automatically. |
|
557 |
+</li> |
|
558 |
+ |
|
559 |
+<li> |
|
560 |
+<b>Help revive an independent Tor client implementation</b> |
|
561 |
+<br /> |
|
562 |
+Priority: <i>Medium</i> |
|
563 |
+<br /> |
|
564 |
+Effort Level: <i>High</i> |
|
565 |
+<br /> |
|
566 |
+Skill Level: <i>Medium to High</i> |
|
567 |
+<br /> |
|
568 |
+Likely Mentors: <i>Karsten, Nick</i> |
|
569 |
+<br /> |
|
570 |
+Reanimate one of the approaches to implement a Tor client in Java, |
|
571 |
+e.g. the <a href="http://onioncoffee.sourceforge.net/">OnionCoffee |
|
572 |
+project</a>, and make it run on <a |
|
573 |
+href="http://code.google.com/android/">Android</a>. The first step |
|
574 |
+would be to port the existing code and execute it in an Android |
|
575 |
+environment. Next, the code should be updated to support the newer Tor |
|
576 |
+protocol versions like the <a href="<svnsandbox>doc/spec/dir-spec.txt">v3 |
|
577 |
+directory protocol</a>. Further, support for requesting or even |
|
578 |
+providing Tor hidden services would be neat, but not required. |
|
579 |
+<br /> |
|
580 |
+The student should be able to understand and write new Java code, including |
|
581 |
+a Java cryptography API. Being able to read C code would be helpful, |
|
582 |
+too. The student should be willing to read the existing documentation, |
|
583 |
+implement code based on it, and refine the documentation |
|
584 |
+when things are underdocumented. This project is mostly about coding and |
|
585 |
+to a small degree about design. |
|
586 |
+</li> |
|
587 |
+ |
|
588 |
+<li> |
|
589 |
+<b>Automatic system tests and automatically starting private Tor networks</b> |
|
590 |
+<br /> |
|
591 |
+Priority: <i>Medium</i> |
|
592 |
+<br /> |
|
593 |
+Effort Level: <i>Medium</i> |
|
594 |
+<br /> |
|
595 |
+Skill Level: <i>Medium</i> |
|
596 |
+<br /> |
|
597 |
+Likely Mentors: <i>Karsten, Nick, Roger</i> |
|
598 |
+<br /> |
|
599 |
+Write a tool that runs automatic system tests in addition |
|
600 |
+to the existing unit tests. The Java-based Tor simulator <a |
|
601 |
+href="https://tor-svn.freehaven.net/svn/puppetor/trunk/">PuppeTor</a> |
|
602 |
+might be a good start for starting up a private Tor network, using it |
|
603 |
+for a while, and verifying that at least parts of it are working. This |
|
604 |
+project requires to conceive a blueprint for performing system tests |
|
605 |
+of private Tor networks, before starting to code. Typical types of |
|
606 |
+tests range from performing single requests over the private network to |
|
607 |
+manipulating exchanged messages and see if nodes handle corrupt messages |
|
608 |
+appropriately. |
|
609 |
+<br /> |
|
610 |
+The student should be able to obtain a good understanding |
|
611 |
+of how Tor works and what problems and bugs could arise to design good |
|
612 |
+test cases. Understanding the existing Tor code structure and documentation is |
|
613 |
+vital. If PuppeTor is used, the student should also be able to understand |
|
614 |
+and possibly extend an existing Java application. This project is partly |
|
615 |
+about design and partly about coding. |
|
616 |
+</li> |
|
617 |
+ |
|
618 |
+<li> |
|
619 |
+<b>Bring moniTor to life</b> |
|
620 |
+<br /> |
|
621 |
+Priority: <i>Medium</i> |
|
622 |
+<br /> |
|
623 |
+Effort Level: <i>Medium</i> |
|
624 |
+<br /> |
|
625 |
+Skill Level: <i>Low to Medium</i> |
|
626 |
+<br /> |
|
627 |
+Likely Mentors: <i>Karsten, Jacob</i> |
|
628 |
+<br /> |
|
629 |
+Implement a <a href="http://www.ss64.com/bash/top.html">top-like</a> |
|
630 |
+management tool for Tor relays. The purpose of such a tool would be |
|
631 |
+to monitor a local Tor relay via its control port and include useful |
|
632 |
+system information of the underlying machine. When running this tool, it |
|
633 |
+would dynamically update its content like top does for Linux processes. |
|
634 |
+<a href="http://archives.seul.org/or/dev/Jan-2008/msg00005.html">This |
|
635 |
+or-dev post</a> might be a good first read. |
|
636 |
+<br /> |
|
637 |
+The student should be familiar |
|
638 |
+with or willing to learn about administering a Tor relay and configuring |
|
639 |
+it via its control port. As an initial prototype is written in Python, |
|
640 |
+some knowledge about writing Python code would be helpful, too. This |
|
641 |
+project is one part about identifying requirements to such a |
|
642 |
+tool and designing its interface, and one part lots of coding. |
|
643 |
+</li> |
|
644 |
+ |
|
645 |
+<li> |
|
646 |
+<b>Tor Exit Scanner improvements</b> |
|
647 |
+<br /> |
|
648 |
+Priority: <i>High</i> |
|
649 |
+<br /> |
|
650 |
+Effort Level: <i>High</i> |
|
651 |
+<br /> |
|
652 |
+Skill Level: <i>High</i> |
|
653 |
+<br /> |
|
654 |
+Likely Mentors: <i>Mike</i> |
|
655 |
+<br /> |
|
656 |
+The Tor exit node scanner 'SoaT', part of the <a |
|
657 |
+href="<svnsandbox>torflow/">Torflow project</a>, makes connections out |
|
658 |
+of each Tor exit node and compares the content it gets back with what it |
|
659 |
+"should" get back. The goal is to notice misconfigured, broken, and even |
|
660 |
+malicious exit relays. Alas, the code is |
|
661 |
+currently written in rather rickety perl and relies on MD5sums of |
|
662 |
+entire documents in order to determine if exit nodes are modifying |
|
663 |
+content. The problem with this is threefold: 1) Perl sucks at life. |
|
664 |
+2) The scanner can't verify pages that are dynamic, and attackers can |
|
665 |
+focus malicious content injection on only those dynamic pages. 3) |
|
666 |
+Pages change after a while (or based on GeoIP) and begin generating |
|
667 |
+false positives. |
|
668 |
+<br /> |
|
669 |
+Ideally, soat.pl would be reimplemented in a sane language with a |
|
670 |
+robust html parser library (since the rest of Torflow is in Python |
|
671 |
+that would be nice, but it is not required), and calculate signatures only for |
|
672 |
+tags and content likely to be targeted by a malicious attacker (script |
|
673 |
+tags, object links, images, css). It should also be robust in the face of |
|
674 |
+changes to content outside of Tor, and ultimately even GeoIP localized |
|
675 |
+content. |
|
676 |
+<br /> |
|
677 |
+This scanner would likely be run by the Directory Authorities and |
|
678 |
+report its results to the control port via the AuthDirBadExit config |
|
679 |
+setting. |
|
680 |
+<br /> |
|
681 |
+</li> |
|
682 |
+ |
|
683 |
+<li> |
|
684 |
+<b>Tor Node Scanner improvements</b> |
|
685 |
+<br /> |
|
686 |
+Priority: <i>High</i> |
|
687 |
+<br /> |
|
688 |
+Effort Level: <i>Medium to High</i> |
|
689 |
+<br /> |
|
690 |
+Skill Level: <i>Medium to High</i> |
|
691 |
+<br /> |
|
692 |
+Likely Mentors: <i>Mike</i> |
|
693 |
+<br /> |
|
694 |
+Similar to the exit scanner (or perhaps even during exit scanning), |
|
695 |
+statistics can be gathered about the reliability of nodes. Nodes that |
|
696 |
+fail too high a percentage of their circuits should not be given |
|
697 |
+Guard status. Perhaps they should have their reported bandwidth |
|
698 |
+penalized by some ratio as well, or just get marked as Invalid. In |
|
699 |
+addition, nodes that exhibit a very low average stream capacity but |
|
700 |
+advertise a very high node bandwidth can also be marked as Invalid. |
|
701 |
+Much of this statistics gathering is already done, it just needs to be |
|
702 |
+transformed into something that can be reported to the Directory |
|
703 |
+Authorities to blacklist/penalize nodes in such a way that clients |
|
704 |
+will listen. |
|
705 |
+<br /> |
|
706 |
+In addition, these same statistics can be gathered about the traffic |
|
707 |
+through a node. Events can be added to the <a |
|
708 |
+href="https://www.torproject.org/svn/torctl/doc/howto.txt">Tor Control |
|
709 |
+Protocol</a> to |
|
710 |
+report if a circuit extend attempt through the node succeeds or fails, and |
|
711 |
+passive statistics can be gathered on both bandwidth and reliability |
|
712 |
+of other nodes via a node-based monitor using these events. Such a |
|
713 |
+scanner would also report information on oddly-behaving nodes to |
|
714 |
+the Directory Authorities, but a communication channel for this |
|
715 |
+currently does not exist and would need to be developed as well. |
|
716 |
+</li> |
|
717 |
+ |
|
718 |
+<li> |
|
719 |
+<b>Help track the overall Tor Network status</b> |
|
720 |
+<br /> |
|
721 |
+Priority: <i>High</i> |
|
722 |
+<br /> |
|
723 |
+Effort Level: <i>Medium</i> |
|
724 |
+<br /> |
|
725 |
+Skill Level: <i>Medium</i> |
|
726 |
+<br /> |
|
727 |
+Likely Mentors: <i>Roger, Nick, Mike</i> |
|
728 |
+<br /> |
|
729 |
+It would be great to set up an automated system for tracking network |
|
730 |
+health over time, graphing it, etc. Part of this project would involve |
|
731 |
+inventing better metrics for assessing network health and growth. Is the |
|
732 |
+average uptime of the network increasing? How many relays are qualifying |
|
733 |
+for Guard status this month compared to last month? What's the turnover |
|
734 |
+in terms of new relays showing up and relays shutting off? Periodically |
|
735 |
+people collect brief snapshots, but where it gets really interesting is |
|
736 |
+when we start tracking data points over time. |
|
737 |
+<br /> |
|
738 |
+Data could be collected from the "Tor Node Scanner" item above, from |
|
739 |
+the server descriptors that each relay publishes, and from other |
|
740 |
+sources. Results over time could be integrated into one of the <a |
|
741 |
+href="https://torstatus.blutmagie.de/">Tor Status</a> web pages, or be |
|
742 |
+kept separate. Speaking of the Tor Status pages, take a look at Roger's |
|
743 |
+<a href="http://archives.seul.org/or/talk/Jan-2008/msg00300.html">Tor |
|
744 |
+Status wish list</a>. |
|
745 |
+</li> |
|
746 |
+ |
|
747 |
+<li> |
|
748 |
+<b>Tor path selection improvements</b> |
|
749 |
+<br /> |
|
750 |
+Priority: <i>High</i> |
|
751 |
+<br /> |
|
752 |
+Effort Level: <i>Low to Medium</i> |
|
753 |
+<br /> |
|
754 |
+Skill Level: <i>High</i> |
|
755 |
+<br /> |
|
756 |
+Likely Mentors: <i>Roger, Nick, Mike</i> |
|
757 |
+<br /> |
|
758 |
+Some simple improvements can be made to Tor's path selection to vastly |
|
759 |
+improve Tor speed. For instance, some of the (unofficial) <a |
|
760 |
+href="http://wiki.noreply.org/noreply/TheOnionRouter/FireFoxTorPerf">Tor |
|
761 |
+Performance Recommendations</a> on the wiki are to increase the number of |
|
762 |
+guards and decrease the CircuitBuildTimeout. Ideally, the client would |
|
763 |
+<a href="http://archives.seul.org/or/talk/Feb-2008/msg00012.html">learn |
|
764 |
+these values by gathering statistics on circuit construction |
|
765 |
+time</a> (and/or using values gained from Torflow), and set the timeouts |
|
766 |
+low enough such that some high percentile (75%, 90%, 1-stddev?) of |
|
767 |
+circuits succeed, yet extremely slow nodes are avoided. This would |
|
768 |
+involve some statistics gathering+basic research, and some changes to |
|
769 |
+Tor path selection code. |
|
770 |
+<br /> |
|
771 |
+In addition, to improve path security, some elements from the <a |
|
772 |
+href="http://www.torproject.org/svn/trunk/doc/spec/proposals/115-two-hop-paths.txt">Two |
|
773 |
+Hop Paths proposal</a> could be done as part of this (since it will |
|
774 |
+likely touch the same code anyways), regardless of the adoption of |
|
775 |
+that proposal. In particular, clients probably should avoid guards that |
|
776 |
+seem to fail an excessive percentage of their circuits through them, |
|
777 |
+and non-firewalled clients should issue a warning if they are only able |
|
778 |
+to connect to a limited set of guard nodes. See also |
|
779 |
+<a href="http://archives.seul.org/or/dev/Feb-2008/msg00003.html">this |
|
780 |
+or-dev post</a>. |
|
781 |
+</li> |
|
782 |
+ |
|
783 |
+<li> |
|
784 |
+<b>Torbutton improvements</b> |
|
785 |
+<br /> |
|
786 |
+Priority: <i>Medium</i> |
|
787 |
+<br /> |
|
788 |
+Effort Level: <i>High</i> |
|
789 |
+<br /> |
|
790 |
+Skill Level: <i>High</i> |
|
791 |
+<br /> |
|
792 |
+Likely Mentors: <i>Mike</i> |
|
793 |
+<br/> |
|
794 |
+Torbutton has a number of improvements that can be made in the post-1.2 |
|
795 |
+timeframe. Most of these are documented as feature requests in the <a |
|
796 |
+href="https://bugs.torproject.org/flyspray/index.php?tasks=all&project=5">Torbutton |
|
797 |
+flyspray section</a>. Good examples include: stripping off node.exit on http |
|
798 |
+headers, more fine-grained control over formfill blocking, improved referrer |
|
799 |
+spoofing based on the domain of the site (a-la <a |
|
800 |
+href="http://addons.mozilla.org/firefox/addon/4513">refspoof extension</a>), |
|
801 |
+tighter integration with Vidalia for reporting Tor status, a New Identity |
|
802 |
+button with Tor integration and multiple identity management, and anything |
|
803 |
+else you might think of. |
|
804 |
+<br /> |
|
805 |
+This work would be independent coding in Javascript and the fun world of <a |
|
806 |
+href="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">XUL</a>, |
|
807 |
+with not too much involvement in the Tor internals. |
|
808 |
+</li> |
|
809 |
+ |
|
810 |
+<li> |
|
811 |
+<b>Porting Polipo to Windows</b> |
|
812 |
+<br /> |
|
813 |
+Priority: <i>Medium</i> |
|
814 |
+<br /> |
|
815 |
+Effort Level: <i>Medium</i> |
|
816 |
+<br /> |
|
817 |
+Skill Level: <i>Medium to High</i> |
|
818 |
+<br /> |
|
819 |
+Likely Mentors: <i>Andrew, Steven, Roger</i> |
|
820 |
+<br /> |
|
821 |
+Help port <a |
|
822 |
+href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> to |
|
823 |
+Windows. Example topics to tackle include: |
|
824 |
+1) handle spaces in path names and understand the filesystem |
|
825 |
+namespace — that is, where application data, personal data, |
|
826 |
+and program data typically reside in various versions of Windows. 2) the |
|
827 |
+ability to handle ipv6 communications. 3) the ability to asynchronously |
|
828 |
+query name servers, find the system nameservers, and manage netbios |
|
829 |
+and dns queries. 4) use native regex capabilities of Windows, rather |
|
830 |
+than using 3rd party GNU regex libraries. 5) manage events and buffers |
|
831 |
+natively (i.e. in Unix-like OSes, Polipo defaults to 25% of ram, in |
|
832 |
+Windows it's whatever the config specifies). 6) some sort of GUI config |
|
833 |
+and reporting tool, bonus if it has a systray icon with right clickable |
|
834 |
+menu options. Double bonus if it's cross-platform compatible. |
|
835 |
+</li> |
|
836 |
+ |
|
837 |
+<li> |
|
838 |
+<b>Make our diagrams beautiful and automated</b> |
|
839 |
+<br /> |
|
840 |
+Priority: <i>Medium</i> |
|
841 |
+<br /> |
|
842 |
+Effort Level: <i>Low</i> |
|
843 |
+<br /> |
|
844 |
+Skill Level: <i>Low</i> |
|
845 |
+<br /> |
|
846 |
+Likely Mentors: <i>Andrew</i> |
|
847 |
+<br /> |
|
848 |
+We need a way to generate the website diagrams (for example, the "How |
|
849 |
+Tor Works" pictures on the <a href="<page overview>">overview page</a> |
|
850 |
+from source, so we can translate them as UTF-8 text rather than edit |
|
851 |
+them by hand with Gimp. We might want to |
|
852 |
+integrate this as an wml file so translations are easy and images are |
|
853 |
+generated in multiple languages whenever we build the website. See the |
|
854 |
+"Translation Wiki" idea above. |
|
855 |
+</li> |
|
856 |
+ |
|
857 |
+<li> |
|
858 |
+<b>Improve the LiveCD offerings for the Tor community</b> |
|
859 |
+<br /> |
|
860 |
+Priority: <i>Low</i> |
|
861 |
+<br /> |
|
862 |
+Effort Level: <i>Low</i> |
|
863 |
+<br /> |
|
864 |
+Skill Level: <i>Medium to High</i> |
|
865 |
+<br /> |
|
866 |
+Likely Mentors: <i>Anonym, Jacob, Roger</i> |
|
867 |
+<br /> |
|
868 |
+How can we make the <a |
|
869 |
+href="http://anonymityanywhere.com/incognito/">Incognito LiveCD</a> |
|
870 |
+easier to maintain, improve, and document? |
|
871 |
+</li> |
|
872 |
+ |
|
873 |
+<li> |
|
874 |
+<b>Contribuisci con delle nuove idee!</b> |
|
875 |
+<br /> |
|
876 |
+Nessuna di queste proposte ti piace? Dai un'occhiata alla <a |
|
877 |
+href="<svnsandbox>doc/design-paper/roadmap-future.pdf">Tor development |
|
878 |
+roadmap</a> per avere altri spunti. |
|
879 |
+</li> |
|
880 |
+ |
|
881 |
+</ol> |
|
882 |
+ |
|
95 | 883 |
<h2><a class="anchor" href="#Coding">Programmazione e design</a></h2> |
96 | 884 |
<ol> |
97 | 885 |
<li>I relay Tor non funzionano bene su Windows XP. Su |
... | ... |
@@ -105,13 +893,7 @@ href="http://www.monkey.org/~provos/libevent/">libevent</a> l' |
105 | 893 |
overlapped IO invece di select() su Windows, per poi adattare Tor |
106 | 894 |
alla nuova interfaccia libevent. Christian King ha dato un |
107 | 895 |
<a href="https://tor-svn.freehaven.net/svn/libevent-urz/trunk/">buon inizio |
108 |
-al lavoro</a> la scorsa estate.</li> |
|
109 |
-<li>Come possiamo fare in modo che l'<a |
|
110 |
-href="http://anonymityanywhere.com/incognito/">Incognito LiveCD</a> |
|
111 |
-sia più facile da mantenere, migliorare e documentare?</li> |
|
112 |
-<li>Il front-end grafico a Tot che preferiamo, |
|
113 |
-<a href="http://vidalia-project.net/">Vidalia</a>, ha bisogno di vari |
|
114 |
-lavori di sviluppo.</li> |
|
896 |
+al lavoro</a> nell'estate 2007.</li> |
|
115 | 897 |
<li>Dobbiamo iniziare a realizzare il nostro <a href="<page |
116 | 898 |
documentation>#DesignDoc">blocking-resistance design</a>. Occorre |
117 | 899 |
ideare il design, modificare varie parti di Tor, adattare |
... | ... |
@@ -126,16 +908,6 @@ adeguare? Questo potrebbe contribuire a molte nuove ricerche. |
126 | 908 |
Vedi la voce <a href="#Research">qui sotto</a> sui confirmation attack per |
127 | 909 |
maggior dettagli sulla ricerca in questo campo — chissà forse al |
128 | 910 |
termine potresti scrivere qualche paper sull'argomento.</li> |
129 |
-<li>Ci serve un framework di testing distribuito. Abbiamo unit tests, |
|
130 |
-ma sarebbe bello avere uno script che avvii una rete Tor, la usi per |
|
131 |
-un po' e verifichi che almeno una parte di essa funzioni.</li> |
|
132 |
-<li>Dai una mano a Mike Perry per la sua libreria <a |
|
133 |
-href="https://torproject.org/svn/torflow/">TorFlow</a> |
|
134 |
-(<a href="https://torproject.org/svn/torflow/TODO">TODO</a>): |
|
135 |
-è una libreria in pythonche usa il <a |
|
136 |
-href="https://torproject.org/svn/torctl/doc/howto.txt">Tor controller |
|
137 |
-protocol</a> per fare costruire a Tor dei circuiti in vari modi, |
|
138 |
-per poi misurarne le prestazioni e rilevarne le anomalie.</li> |
|
139 | 911 |
<li>Tor 0.1.1.x e successivi includono il supporto per acceleratori crittografici hardware |
140 | 912 |
tramite OpenSSL. Nessuno tuttavia lo ha ancora testato. C'è qualcuno che vuole |
141 | 913 |
prendere una scheda e farci sapere come va?</li> |
... | ... |
@@ -156,11 +928,6 @@ UDP</a> — facci sapere se presentano dei problemi.</li> |
156 | 928 |
<li>Non ci manca molto per avere supporto IPv6 per indirizzi destinazione |
157 | 929 |
(sugli exit node). Se per te IPv6 è molto importante, questo è |
158 | 930 |
il punto da cui cominciare.</li> |
159 |
-<li>Se nessuno dei punti qui sopra è di tuo gusto, dai un'occhiata alla <a |
|
160 |
-href="<svnsandbox>doc/design-paper/roadmap-future.pdf">Tor development |
|
161 |
-roadmap</a> per ulteriori spunti.</li> |
|
162 |
-<li>Se non vedi elencata qui la tua idea, forse è comunque importante e ne abbiamo bisogno! Contattaci |
|
163 |
-e scoprilo.</li> |
|
164 | 931 |
</ol> |
165 | 932 |
|
166 | 933 |
<a id="Research"></a> |
... | ... |
@@ -251,8 +1018,10 @@ puzzle sono la soluzione giusta? Quali altri approcci pratici esistono? Un premi |
251 | 1018 |
se sono compatibili col protocollo Tor attuale.</li> |
252 | 1019 |
</ol> |
253 | 1020 |
|
1021 |
+<p> |
|
254 | 1022 |
<a href="<page contact>">Facci sapere</a> se hai fatto progressi in qualcuno di |
255 | 1023 |
questi campi! |
1024 |
+</p> |
|
256 | 1025 |
|
257 | 1026 |
</div><!-- #main --> |
258 | 1027 |
|
259 | 1028 |