tor-webwml.git

@@ -0,0 +1,179 @@

+## translation metadata

+# Based-On-Revision: 15530

+# Last-Translator: djhasis(at)gmail.com

+

+#include "head.wmi" TITLE="Tor: Lahjoita!" CHARSET="UTF-8"

+

+<div class="main-column">

+

+<h2>Lahjoita Tor-projektille!</h2>

+<hr />

+

+<p>

+Jos pidät Tor-ohjelmasta tai -verkosta ja haluat auttaa tukemalla Tor-projektia, ole hyvä ja harkitse lahjoituksen tekoa auttaakseen meitä jatkamaan työtämme.  Tarjomme muutaman tavan tehdä lahjoituksen:</p>

+<ul>

+<li><a href="#check">Check, Money Order, or Postal Order</a></li>

+<li><a href="#paypal">PayPal</a></li>

+<li><a href="#wire">ACH/e-check/Wire Transfers</a></li>

+<li><a href="#eurobank">European Bank Transfers</a></li>

+<li><a href="#funds">What happens to my donation?</a></li>

+</ul>

+

+<p>As of December 2006, Tor is a US 501[c][3] research/educational

+nonprofit.  Donations to The Tor Project may be tax deductible to persons

+who are in the US or who pay taxes in countries with reciprocity with

+the US on charitable donations.  If you have any questions, please

+<a href="mailto:donations@torproject.org">contact us</a> directly.  We're happy

+to discuss major gifts, planned giving, and public acknowledgement of donations

+with you.

+</p>

+

+<p>Donations of $65 or more qualify you for a <a href="<page

+tshirt>">bright green Tor t-shirt</a>. Help us keep Tor under <a

+href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#Funding">active

+development</a>!

+</p>

+

+<a id="check"></a>

+<h3><a class="anchor" href="#check">Checks, Money Orders, and Postal

+Orders</a></h3>

+<p>

+These payments can be sent to:

+</p>

+<blockquote><p>

+The Tor Project<br />

+122 Scott Circle<br />

+Dedham, MA  02026 USA</p>

+</blockquote>

+

+<p>

+Attention US citizens: if you would like an acknowledgement letter,

+please inform us with your donation.  A canceled check, money/postal order receipt, or

+appraisal of donated property are valid records according to the IRS.  

+</p>

+

+<a id="paypal"></a>

+<h3><a class="anchor" href="#paypal">PayPal</a></h3>

+<form id="subscribe" action="https://www.paypal.com/cgi-bin/webscr"

+method="post">

+  <p>

+The most useful approach is to become a Tor project "member" for a

+<b>recurring payment</b> each month. Consistent

+donations let us worry less about fund-raising and focus more on

+development. You can become a member by clicking on this button (you

+will need a <a

+href="http://paypal.com/">PayPal</a> account):<br />

+<input type="radio" name="a3" value="50.00" />$50

+<input type="radio" name="a3" value="20.00" checked="checked" />$20

+<input type="radio" name="a3" value="10.00" />$10

+<input type="radio" name="a3" value="5.00" />$5

+<input type="hidden" name="p3" value="1" />

+<input type="hidden" name="t3" value="M" />

+<input type="hidden" name="sra" value="1" />

+<input type="hidden" name="src" value="1" />

+<input type="hidden" name="no_shipping" value="1" />

+<input type="hidden" name="no_note" value="1" />

+<input type="image"

+ src="https://www.paypal.com/en_US/i/btn/btn_donateCC_LG.gif" name="submit"

+ alt="Make payments with PayPal - it's fast, free and secure!">

+<input type="hidden" name="cmd" value="_xclick-subscriptions" />

+<input type="hidden" name="business" value="donations@torproject.org" />

+<input type="hidden" name="item_name" value="Tor Project Membership" />

+<input type="hidden" name="return" value="https://www.torproject.org/">

+<input type="hidden" name="cancel_return"

+ value="https://www.torproject.org/donate">

+</p>

+</form>

+

+<form id="donate" action="https://www.paypal.com/cgi-bin/webscr" method="post">

+<p>You can also make a <b>one-time donation</b> (via PayPal, but

+doesn't require any account):<br />

+<input type="radio" name="amount" value="100.00" />$100

+<input type="radio" name="amount" value="50.00" />$50

+<input type="radio" name="amount" value="20.00" checked="checked" />$20

+<input type="radio" name="amount" value="10.00" />$10

+<input type="radio" name="amount" value="" />other

+<input type="hidden" name="no_shipping" value="1" />

+<input type="image"

+ src="https://www.paypal.com/en_US/i/btn/btn_donateCC_LG.gif"

+ name="submit" alt="Make payments with PayPal - it's fast, free and secure!">

+<input type="hidden" name="cmd" value="_xclick" />

+<input type="hidden" name="business" value="donations@torproject.org" />

+<input type="hidden" name="item_name" value="Tor" />

+<input type="hidden" name="return" value="https://www.torproject.org/">

+<input type="hidden" name="cancel_return" value="https://www.torproject.org/donate">

+</p>

+</form>

+

+<a id="wire"></a>

+<h3><a class="anchor" href="#wire">ACH/e-check/Wire Transfers</a></h3>

+<p>In the US, ACH or e-check transfers are a fine way to donate.  

+We're happy to accept wire transfers over US$100.  Domestic United

+States ACH/e-check transfers are normally free for the sender, whereas wire transfers will incur fees.

+If you are located in Europe, <a href="#eurobank">please see below</a>.</p>

+

+<p>

+Organization Address:<br />

+The Tor Project<br />

+122 Scott Circle<br />

+Dedham, MA 02026<br />

+</p>

+<p>

+account number: 63904958202<br />

+routing number: 011075150<br />

+SWIFT Code: SVRNUS33//FW011075150<br />

+</p>

+<p>

+Bank Address:<br />

+Sovereign Bank<br />

+1130 Berkshire Boulevard<br />

+Wyomissing, PA 19610<br />

+</p>

+

+<a id="eurobank"></a>

+<h3><a class="anchor" href="#eurobank">European Bank Transfers</a></h3>

+<p>In Europe, we have a funding arrangement with the <a

+href="http://www.ccc.de/">Chaos Computer Club</a>.  Your donations go

+into a separate bank account managed by the CCC, and they use the funds

+to do beneficial activities for Tor in Europe.  Residents from any of the <a

+href="http://en.wikipedia.org/wiki/Single_Euro_Payments_Area">31 SEPA

+member states</a> can wire up to 50.000

+Euro at the cost of a domestic transaction (i.e., usually free if

+submitted electronically).</p>

+

+<p>

+The account information is:<br />

+Wau Holland Stiftung<br />

+IBAN DE57 5204 0021 0277 281202<br />

+SWIFT BIC COBADEFFXXX<br />

+</p>

+<p>

+Classic style German account information is:<br />

+Konto: 2772812-02<br />

+Inhaber: Wau Holland Stiftung<br />

+Bank: Commerzbank Kassel<br />

+BLZ: 52040021<br />

+</p>

+<p>WHS issues a donation receipt upon request (if provided with address

+information).

+</p>

+

+<a id="funds"></a>

+<h3><a class="anchor" href="#funds">What happens to my donation?</a></h3>

+<p>Your funds are deposited into our general fund.  You join our 

+<a href="<page sponsors>">many sponsors</a> in funding the future of Tor and online anonymity.  

+In 2007, the Tor Project spent and received its funds as follows: </p>

+<p><img

+src="http://chart.apis.google.com/chart?cht=p&chtt=Who%20funds%20The%20Tor%20Project?&chco=00df00&chd=t:56,31,13&chs=450x225&chl=Governments%2056%|NGOs%2031%|Individuals%2013%" alt="Who funds the Tor Project?"/>

+<img

+src="http://chart.apis.google.com/chart?cht=p&amp;chtt=How%20does%20The%20Tor%20Project%20allocate%20funds?&amp;chco=00df00&amp;chd=t:72,13,15&amp;chs=450x225&amp;chl=Development%2072%|Operational%2013%|Taxes%2015%" alt="How does the Tor Project allocate funds?"/></p>

+

+<hr />

+<strong>The Tor Project respects the confidentiality of our supporters,

+when requested. We do not lend, rent, or sell our lists of donors at

+any time.</strong>

+

+  </div><!-- #main -->

+

+#include <foot.wmi>

+

@@ -196,7 +196,7 @@

 </tr>

 <tr bgcolor="e5e5e5">

-<td>Lähdekoodipaketit</td>

+<td>Lähdekoodit</td>

 <td>

 <a href="<package-source-stable>"><version-stable></a> (<a href="<package-source-stable-sig>">sig</a>)

 </td>

@@ -353,10 +353,9 @@ href="<page mirrors>">on lista palvelimista, jotka ovat kopioita Tor-sivustosta<

 <a id="Stable"></a>

 <a id="Testing"></a>

 <p>

-For a list of what has changed in each stable Tor release, see the

-<a href="<svnsandbox>ReleaseNotes">ReleaseNotes</a>. For a list of

-changes in both stable and development versions, see the

-<a href="<svnsandbox>ChangeLog">ChangeLog</a>.

+Vakaan Tor-julkaisun muutoksia voi lukea englanninkielellä tiedostosta

+<a href="<svnsandbox>ReleaseNotes">ReleaseNotes / Julkaisutiedot</a>. Muutokset sekä vakaissa ja kehitysversioissa voi lukea englanninkielellä  tiedostosta 

+<a href="<svnsandbox>ChangeLog">ChangeLog / Muutosloki</a>.

 </p>

 </div><!-- #main -->

@@ -200,8 +200,7 @@ all the issues</a>.

 <h2><a class="anchor" href="#packagediff">Mitä eroja on vakaalla &amp; epävakaalla</a></h2>

 <p>

-Stable packages are released when we believe the features and code will

-not change for many months. These typically include a stable version of Vidalia, Privoxy, and Torbutton.

+Vakaat julkaisut ovat sillaisia joiden toiminnot ja koodi eivät tule muuttumaan useampaan kuukauteen. 

 </p>

 <p>

 Unstable/Alpha packages are released so you can help us test new features and bugfixes. Even though they have a higher version number

@@ -312,7 +311,7 @@ for you.  In all cases, you must configure Tor itself through your own editor.

 <tr bgcolor="#e5e5e5">

   <td>

-    Source tarballs<br />

+    Lähdekoodipaketit<br />

     <kbd>./configure &amp;&amp; make &amp;&amp; src/or/tor</kbd>

   </td>

   <td>

@@ -351,10 +350,9 @@ href="<page mirrors>">on lista palvelimista, jotka ovat kopioita Tor-sivustosta<

 <a id="Stable"></a>

 <a id="Testing"></a>

 <p>

-For a list of what has changed in each stable Tor release, see the

-<a href="<svnsandbox>ReleaseNotes">ReleaseNotes</a>. For a list of

-changes in both stable and development versions, see the

-<a href="<svnsandbox>ChangeLog">ChangeLog</a>.

+Vakaan Tor-julkaisun muutoksia voi lukea englanninkielellä tiedostosta

+<a href="<svnsandbox>ReleaseNotes">ReleaseNotes / Julkaisutiedot</a>. Muutokset sekä vakaissa ja kehitysversioissa voi lukea englanninkielellä  tiedostosta 

+<a href="<svnsandbox>ChangeLog">ChangeLog / Muutosloki</a>.

 </p>

 </div><!-- #main -->

@@ -0,0 +1,199 @@

+## translation metadata

+# Based-On-Revision: 15491

+# Last-Translator: djhasis(at)gmail.com

+

+#include "head.wmi" TITLE="Tor: Henkilöt" CHARSET="UTF-8" CHARSET="UTF-8"

+

+<div class="main-column">

+

+<h2>Tor: Henkilöt</h2>

+<hr />

+

+<p>The Tor Project is a 501(c)(3) non-profit based in

+the United States. Yrityksen virallinen osoite on:<br>

+<blockquote>

+The Tor Project<br>

+122 Scott Circle<br>

+Dedham, MA  02026 USA<br>

+</blockquote>

+

+<p>Yritys koostuu monista vapaaehtoisista henkilöistä sekä muutamasta työntekijästä.</p>

+

+<a id="Core"></a>

+<h3><a class="anchor" href="#Core">PääTor-henkilöt:</a></h3>

+

+<dl>

+<dt>Jacob Appelbaum</dt><dd>Runs the <a

+href="http://check.torproject.org/">Tor DNSEL</a> <a

+href="http://exitlist.torproject.org/">site</a>, the <a

+href="https://translation.torproject.org/">Tor Translation Portal</a>, and also

+the in-progress Tor weather site.</dd>

+<dt>Roger Dingledine (Tor project leader; Director)</dt><dd>Original

+developer of Tor; now plays pretty much all the roles to keep

+everything on track.</dd>

+<dt>Matt Edman</dt><dd>Developer for <a

+href="http://vidalia-project.net/">Vidalia</a>, a cross-platform Tor GUI

+included in the Windows and OS X bundles.</dd>

+<dt>Andrew Lewman (Director)</dt><dd>Manages building packages for

+Windows, OS X, Red Hat, and SuSE. Also provides common sense on topics

+like how to run a non-profit and generally helps keep everything moving

+forward.</dd>

+<dt>Karsten Loesing</dt><dd> Worked during the 2007 Google Summer of

+Code on <a

+href="https://www.torproject.org/svn/trunk/doc/spec/proposals/114-distributed-storage.txt">distributing

+and securing the publishing and fetching of hidden service

+descriptors</a>.</dd>

+<dt>Nick Mathewson (Chief architect; Director)</dt><dd>One of the

+three original designers of Tor; does a lot of the ongoing design work.

+One of the two main developers, along with Roger.</dd>

+<dt>Steven Murdoch (Researcher)</dt><dd>Researcher at the University

+of Cambridge, currently funded by The Tor Project to improve

+the security, performance, and usability of Tor. Creator of the

+<a href="https://torbrowser.torproject.org/">Tor Browser Bundle</a>.</dd>

+<dt>Peter Palfrader</dt><dd>Manages the Debian packages,

+runs one of the directory authorities, runs the website and the wiki,

+and generally helps out a lot.</dd>

+<dt>Mike Perry</dt><dd>Author of <a

+href="https://www.torproject.org/svn/torflow/README">TorFlow</a>, a Tor

+controller that builds paths through the Tor network and

+measures various properties and behaviors. Working now on a <a

+href="https://torbutton.torproject.org/dev/">much more comprehensive

+version of Torbutton</a>.</dd>

+<dt>Paul Syverson</dt><dd>Inventor of <a

+href="http://www.onion-router.net/">Onion Routing</a>, original designer

+of Tor along with Roger and Nick, and project leader for original design,

+development, and deployment of Tor. Currently helps out with research

+and design.</dd>

+</dl>

+

+<a id="Board"></a>

+<h3><a class="anchor" href="#Board">Tor-projektin johtokunta:</a></h3>

+

+<dl>

+<dt>Ian Goldberg (Director)</dt><dd>Cryptographer,

+privacy expert, and professor; one of the designers of <a

+href="http://www.cypherpunks.ca/otr/">Off-the-Record Messaging</a>.</dd>

+<dt>Xianghui (Isaac) Mao (Director)</dt><dd>Chinese blogging and privacy

+activist.  His current activities can be found at <a

+href="http://isaacmao.com/">his website</a>.<dd>

+<dt>Wendy Seltzer (Director)</dt><dd>Lawyer,

+cyberlaw professor, and founder of <a

+href="http://chillingeffects.org/">ChillingEffects.org</a>.</dd>

+<dt>Fred von Lohmann (Director)</dt><dd>Fred is a Senior

+Intellectual Property Attorney at the Electronic Frontier

+Foundation (EFF). His complete bio can be found at the <a

+href="http://www.eff.org/about/staff/?f=fred_von_lohmann.html">EFF

+Staff Site</a>.</dd>

+<dt>Along with Roger, Nick, and Andrew listed above as Directors.</dt>

+</dl>

+

+<a id="Translators"></a>

+<h3><a class="anchor" href="#Translators">Pääkääntäjät:</a></h3>

+

+<dl>

+<dt>Bogdan Drozdowski</dt><dd><a

+href="https://www.torproject.org/index.html.pl">puolankieli</a>.</dd>

+<dt>fredzupy</dt><dd><a

+href="https://www.torproject.org/index.html.fr">ranskankieli</a>.</dd>

+<dt>Ruben Garcia</dt><dd><a

+href="https://www.torproject.org/index.html.es">espanjankieli</a>.</dd>

+<dt>Jens Kubieziel</dt><dd><a

+href="https://www.torproject.org/index.html.de">saksankieli</a>.</dd>

+<dt>Pei Hanru</dt><dd><a

+href="https://www.torproject.org/index.html.zh-cn">yksinkertaistettu kiinankieli</a>.</dd>

+<dt>Jan Reister</dt><dd><a

+href="https://www.torproject.org/index.html.it">italiankieli</a>.</dd>

+<dt>Masaki Taniguchi</dt><dd><a

+href="https://www.torproject.org/index.html.ja">japaninkieli</a>.</dd>

+<dt>Jan Woning</dt><dd><a

+href="https://www.torproject.org/index.html.nl">hollanninkieli</a>.</dd>

+<dt>ygrek</dt><dd><a

+href="https://www.torproject.org/index.html.ru">venäjänkieli</a>.</dd>

+</dl>

+

+<a id="Volunteers"></a>

+<h3><a class="anchor" href="#Volunteers">Monet vapaaehtoiset:</a></h3>

+

+<dl>

+<dt>Anonym</dt><dd>Maintainer of the Incognito LiveCD.</dd>

+<dt>Kevin Bankston</dt><dd>EFF lawyer who helped write the <a

+href="<page eff/tor-legal-faq>">Tor Legal FAQ</a> and

+tirelessly answers the phone when somebody in the world has a legal

+question about Tor.</dd>

+<dt>Jeff Blum</dt><dd>Our Site Editor volunteer who is helping to update

+the content of the Tor website.</dd>

+<dt>Kasimir Gabert</dt><dd>Maintains the <a

+href="https://torstatus.kgprog.com/">TorStatus</a> statistics pages.</dd>

+<dt>Geoff Goodell</dt><dd>Runs one of the directory authorities, used to

+run the Blossom project which uses Tor as its overlay network, and runs

+the <a href="http://lefkada.eecs.harvard.edu/cgi-bin/exit.py">exit.py</a>

+Tor relay list.</dd>

+<dt>Robert Hogan</dt><dd>Developer for the <a

+href="http://tork.sf.net/">TorK</a> Tor controller.</dd>

+<dt>Fabian Keil</dt><dd>One of the core Privoxy developers, and also a

+Tor fan. He's the reason Tor and Privoxy still work well together.</dd>

+<dt>Julius Mittenzwei</dt><dd>A lawyer with the CCC in

+Germany. Coordinates the German Tor community with respect to legal

+questions and concerns.</dd>

+<dt>Shava Nerad</dt><dd>Our former Development Director.  She works on PR and community relations.</dd>

+<dt>Lasse Øverlier</dt><dd>Writes research papers on Tor: attacks,

+defenses, and resource management, especially for hidden services.</dd>

+<dt>Martin Peck and Kyle Williams</dt><dd>Developers for

+JanusVM, a VMWare-based

+transparent Tor proxy that makes Tor easier to set up and use.</dd>

+<dt>Steve Topletz</dt><dd>Developer for Torpark (now called Xerobank

+Browser), a preconfigured Tor+Firefox bundle for Windows.</dd>

+<dt>Tup (a pseudonym -- he's managed to stay anonymous even from

+us!)</dt><dd>Periodically adds new features for making Tor more

+transparent to use. Also maintains the <a

+href="http://p56soo2ibjkx23xo.onion/">TorDNSEL code</a>.</dd>

+<dt>Ethan Zuckerman</dt><dd>A blogger who has written some

+<a href="http://www.ethanzuckerman.com/blog/?p=1019">interesting</a>

+<a href="http://advocacy.globalvoicesonline.org/tools/guide/">tutorials</a>

+for how, when, and whether to use Tor. He also teaches activists around

+the world about Tor and related tools.</dd>

+<dt>All our relay operators, people who write <a

+href="http://freehaven.net/anonbib/">research papers</a> about Tor,

+people who teach others about Tor, etc.</dt>

+</dl>

+

+<a id="GSoC"></a>

+<a id="Past"></a>

+<h3><a class="anchor" href="#Past">Aikaisemmille työntekijöille kiitokset:</a></h3>

+

+<dl>

+<dt>Benedikt Boss</dt><dd>Worked during the 2007 Google Summer of Code on <a

+href="https://svn.torproject.org/svn/topf/trunk/README">TOPF</a>,

+a fuzzer for Tor; mentored by Roger.</dd>

+<dt>Ren Bucholz</dt><dd>Our fine logo and images.</dd>

+<dt>Pat Double</dt><dd>Creator of the Incognito LiveCD.</dd>

+<dt>Justin Hipple</dt><dd>The other developer for Vidalia.</dd>

+<dt>Christian King</dt><dd> Worked during the 2007 Google Summer of Code

+on making Tor relays stable on

+Windows, by developing a <a

+href="https://svn.torproject.org/svn/libevent-urz/trunk/README">buffer

+implementation for libevent</a>; mentored by Nick.</dd>

+<dt>Joe Kowalski</dt><dd>Original author and provider of the torstatus

+script formerly run on nighteffect.</dd>

+<dt>Adam Langley</dt><dd>Our fine eventdns code.</dd>

+<dt>Rebecca McKinnon</dt><dd>Former Director of Tor.  Co-Founder of <a

+href="http://www.globalvoicesonline.org/">Global Voices Online</a>.</dd>

+<dt>Matej Pfajfar</dt><dd>Author of the original onion routing code that

+Tor is based on, so we didn't have to start from scratch.</dd>

+<dt>Johannes Renner</dt><dd> Worked during the 2007 Google Summer of

+Code on modifying <a

+href="https://www.torproject.org/svn/torflow/README">TorFlow</a>

+to measure various properties of the Tor network; mentored by Mike

+Perry.</dd>

+<dt>Scott Squires</dt><dd>Alkuperäinen kehittäjä lisäosalle <a

+href="https://torbutton.torproject.org/">Torbutton</a>.</dd>

+</dl>

+

+<p>Please don't contact us individually about Tor topics &mdash; if

+you have a problem or question, please look through the <a href="<page

+contact>">contact page</a> for appropriate addresses.</p>

+

+  </div><!-- #main -->

+

+#include <foot.wmi>

+

@@ -0,0 +1,1173 @@

+## translation metadata

+# Based-On-Revision: 15123

+# Last-Translator: djhasis(at)gmail.com

+

+#include "head.wmi" TITLE="Tor: Auta" CHARSET="UTF-8"

+

+<div class="main-column">

+

+<!-- PUT CONTENT AFTER THIS TAG -->

+<h2>A few things everyone can do now:</h2>

+<ol>

+<li>Please consider <a href="<page docs/tor-doc-relay>">running

+a relay</a> to help the Tor network grow.</li>

+<li>Tell your friends! Get them to run relays. Get them to run hidden

+services. Get them to tell their friends.</li>

+<li>If you like Tor's goals, please <a href="<page donate>">take a moment

+to donate to support further Tor development</a>. We're also looking

+for more sponsors — if you know any companies, NGOs, agencies,

+or other organizations that want anonymity / privacy / communications

+security, let them know about us.</li>

+<li>We're looking for more <a href="<page torusers>">good examples of Tor

+users and Tor use cases</a>. If you use Tor for a scenario or purpose not

+yet described on that page, and you're comfortable sharing it with us,

+we'd love to hear from you.</li>

+</ol>

+

+<a id="Usability"></a>

+<h2><a class="anchor" href="#Usability">Supporting Applications</a></h2>

+<ol>

+<li>We need more good ways to intercept DNS requests so they don't "leak" their

+request to a local observer while we're trying to be anonymous. (This

+happens because the application does the DNS resolve before going to

+the SOCKS proxy.)</li>

+<li>Tsocks/dsocks items:

+<ul>

+<li>We need to <a

+href="https://wiki.torproject.org/noreply/TheOnionRouter/TSocksPatches">apply

+all our tsocks patches</a> and maintain a new fork. We'll host it if

+you want.</li>

+<li>We should patch Dug Song's "dsocks" program to use Tor's

+<i>mapaddress</i> commands from the controller interface, so we

+don't waste a whole round-trip inside Tor doing the resolve before

+connecting.</li>

+<li>We need to make our <i>torify</i> script detect which of tsocks or

+dsocks is installed, and call them appropriately. This probably means

+unifying their interfaces, and might involve sharing code between them

+or discarding one entirely.</li>

+</ul>

+</li>

+<li>People running relays tell us they want to have one BandwidthRate

+during some part of the day, and a different BandwidthRate at other

+parts of the day. Rather than coding this inside Tor, we should have a

+little script that speaks via the <a href="<page gui/index>">Tor

+Controller Interface</a>, and does a setconf to change the bandwidth

+rate. There is one for Unix and Mac already (it uses bash and cron),

+but Windows users still need a solution.

+</li>

+<li>Tor can <a

+href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#ChooseEntryExit">exit

+the Tor network from a particular exit node</a>, but we should be able

+to specify just a country and have something automatically pick. The

+best bet is to fetch Blossom's directory also, and run a local Blossom

+client that fetches this directory securely (via Tor and checking its

+signature), intercepts <tt>.country.blossom</tt> hostnames, and does

+the right thing.</li>

+<li>Speaking of geolocation data, somebody should draw a map of the Earth

+with a pin-point for each Tor relay. Bonus points if it updates as the

+network grows and changes. Unfortunately, the easy ways to do this involve

+sending all the data to Google and having them draw the map for you. How

+much does this impact privacy, and do we have any other good options?</li>

+</ol>

+

+<a id="Documentation"></a>

+<h2><a class="anchor" href="#Documentation">Documentation</a></h2>

+<ol>

+<li>Please help Matt Edman with the documentation and how-tos for his

+Tor controller,

+<a href="http://vidalia-project.net/">Vidalia</a>.</li>

+<li>Evaluate and document

+<a href="https://wiki.torproject.org/wiki/TheOnionRouter/TorifyHOWTO">our

+list of programs</a> that can be configured to use Tor.</li>

+<li>We need better documentation for dynamically intercepting

+connections and sending them through Tor. tsocks (Linux), dsocks (BSD),

+and freecap (Windows) seem to be good candidates, as would better

+use of our new TransPort feature.</li>

+<li>We have a huge list of <a href="https://wiki.torproject.org/noreply/TheOnionRouter/SupportPrograms">potentially useful

+programs that interface to Tor</a>. Which ones are useful in which

+situations? Please help us test them out and document your results.</li>

+<li>Help translate the web page and documentation into other

+languages. See the <a href="<page translation>">translation

+guidelines</a> if you want to help out. We especially need Arabic or

+Farsi translations, for the many Tor users in censored areas.</li>

+</ol>

+

+<a id="Coding"></a>

+<a id="Summer"></a>

+<a id="Projects"></a>

+<h2><a class="anchor" href="#Projects">Good Coding Projects</a></h2>

+

+<p>

+You may find some of these projects to be good <a href="<page

+gsoc>">Google Summer of Code 2008</a> ideas. We have labelled each idea

+with how useful it would be to the overall Tor project

+(priority), how much work we expect it would be (effort level), how much

+clue you should start with (skill level), and which of our <a href="<page

+people>#Core">core developers</a> would be good mentors. There are plenty

+of other good ideas to work on too &mdash; see for example the <a

+href="<svnsandbox>doc/spec/proposals/">current proposals</a> list, or

+just make up your own ideas.

+</p>

+

+<ol>

+

+<li>

+<b>Tor Exit Scanner improvements</b>

+<br />

+Priority: <i>High</i>

+<br />

+Effort Level: <i>High</i>

+<br />

+Skill Level: <i>High</i>

+<br />

+Likely Mentors: <i>Mike</i>

+<br />

+Applications as of 1 Apr 00:00 UTC: <i>5</i>

+<br />

+The Tor exit node scanner 'SoaT', part of the <a

+href="<svnsandbox>torflow/">Torflow project</a>, makes connections out

+of each Tor exit node and compares the content it gets back with what it

+"should" get back. The goal is to notice misconfigured, broken, and even

+malicious exit relays. Alas, the code is

+currently written in rather rickety perl and relies on MD5sums of

+entire documents in order to determine if exit nodes are modifying

+content. The problem with this is threefold: 1) Perl sucks at life.

+2) The scanner can't verify pages that are dynamic, and attackers can

+focus malicious content injection on only those dynamic pages. 3)

+Pages change after a while (or based on GeoIP) and begin generating

+false positives.

+<br />

+Ideally, soat.pl would be reimplemented in a sane language with a

+robust html parser library (since the rest of Torflow is in Python

+that would be nice, but it is not required), and calculate signatures only for

+tags and content likely to be targeted by a malicious attacker (script

+tags, object links, images, css). It should also be robust in the face of

+changes to content outside of Tor, and ultimately even GeoIP localized

+content.

+<br />

+This scanner would likely be run by the Directory Authorities and

+report its results to the control port via the AuthDirBadExit config

+setting.

+<br />

+</li>

+

+<li>

+<b>Tor Node Scanner improvements</b>

+<br />

+Priority: <i>High</i>

+<br />

+Effort Level: <i>Medium to High</i>

+<br />

+Skill Level: <i>Medium to High</i>

+<br />

+Likely Mentors: <i>Mike</i>

+<br />

+Applications as of 1 Apr 00:00 UTC: <i>1</i>

+<br />

+Similar to the exit scanner (or perhaps even during exit scanning),

+statistics can be gathered about the reliability of nodes. Nodes that

+fail too high a percentage of their circuits should not be given

+Guard status. Perhaps they should have their reported bandwidth

+penalized by some ratio as well, or just get marked as Invalid. In

+addition, nodes that exhibit a very low average stream capacity but

+advertise a very high node bandwidth can also be marked as Invalid.

+Much of this statistics gathering is already done, it just needs to be

+transformed into something that can be reported to the Directory

+Authorities to blacklist/penalize nodes in such a way that clients

+will listen.

+<br />

+In addition, these same statistics can be gathered about the traffic

+through a node. Events can be added to the <a

+href="https://www.torproject.org/svn/torctl/doc/howto.txt">Tor Control

+Protocol</a> to

+report if a circuit extend attempt through the node succeeds or fails, and

+passive statistics can be gathered on both bandwidth and reliability

+of other nodes via a node-based monitor using these events. Such a

+scanner would also report information on oddly-behaving nodes to

+the Directory Authorities, but a communication channel for this

+currently does not exist and would need to be developed as well.

+</li>

+

+<li>

+<b>Help track the overall Tor Network status</b>

+<br />

+Priority: <i>High</i>

+<br />

+Effort Level: <i>Medium</i>

+<br />

+Skill Level: <i>Medium</i>

+<br />

+Likely Mentors: <i>Roger, Nick, Mike</i>

+<br />

+It would be great to set up an automated system for tracking network

+health over time, graphing it, etc. Part of this project would involve

+inventing better metrics for assessing network health and growth. Is the

+average uptime of the network increasing? How many relays are qualifying

+for Guard status this month compared to last month? What's the turnover

+in terms of new relays showing up and relays shutting off? Periodically

+people collect brief snapshots, but where it gets really interesting is

+when we start tracking data points over time.

+<br />

+Data could be collected from the "Tor Node Scanner" item above, from

+the server descriptors that each relay publishes, and from other

+sources. Results over time could be integrated into one of the <a

+href="https://torstatus.blutmagie.de/">Tor Status</a> web pages, or be

+kept separate. Speaking of the Tor Status pages, take a look at Roger's

+<a href="http://archives.seul.org/or/talk/Jan-2008/msg00300.html">Tor

+Status wish list</a>.

+</li>

+

+<li>

+<b>Tor path selection improvements</b>

+<br />

+Priority: <i>High</i>

+<br />

+Effort Level: <i>Low to Medium</i>

+<br />

+Skill Level: <i>High</i>

+<br />

+Likely Mentors: <i>Roger, Nick, Mike</i>

+<br />

+Applications as of 1 Apr 00:00 UTC: <i>3</i>

+<br />

+Some simple improvements can be made to Tor's path selection to vastly

+improve Tor speed. For instance, some of the (unofficial) <a

+href="http://wiki.noreply.org/noreply/TheOnionRouter/FireFoxTorPerf">Tor

+Performance Recommendations</a> on the wiki are to increase the number of

+guards and decrease the CircuitBuildTimeout. Ideally, the client would

+<a href="http://archives.seul.org/or/talk/Feb-2008/msg00012.html">learn

+these values by gathering statistics on circuit construction

+time</a> (and/or using values gained from Torflow), and set the timeouts

+low enough such that some high percentile (75%, 90%, 1-stddev?) of

+circuits succeed, yet extremely slow nodes are avoided. This would

+involve some statistics gathering+basic research, and some changes to

+Tor path selection code.

+<br />

+In addition, to improve path security, some elements from the <a

+href="http://www.torproject.org/svn/trunk/doc/spec/proposals/115-two-hop-paths.txt">Two

+Hop Paths proposal</a> could be done as part of this (since it will

+likely touch the same code anyways), regardless of the adoption of

+that proposal. In particular, clients probably should avoid guards that

+seem to fail an excessive percentage of their circuits through them,

+and non-firewalled clients should issue a warning if they are only able

+to connect to a limited set of guard nodes. See also

+<a href="http://archives.seul.org/or/dev/Feb-2008/msg00003.html">this

+or-dev post</a>.

+</li>

+

+<li>

+<b>Translation Wiki</b>

+<br />

+Priority: <i>High</i>

+<br />

+Effort Level: <i>Medium</i>

+<br />

+Skill Level: <i>Medium</i>

+<br />

+Likely Mentors: <i>Jacob</i>

+<br />

+We need a way to edit and translate sections of the website. Currently

+the website is made up of a bunch of <a href="<svnwebsite>en/">wml

+files</a>, and <a href="<page translation>">translators</a> fetch these

+wml files, translate them in an editor, and either send us the translation

+or use svn to commit them back. The current "cost" of publication of

+website changes is quite high even for English language users. For a

+single word change or any type of

+minor change, the page may never be corrected or translated. It would

+be nice to have a wiki that was specifically geared towards translation

+and would somehow track the upstream (English) versions to indicate when

+a fresh translation is needed, like our current

+<a href="<page translation-status>">translation status page</a>. This

+seems mostly like a job for a wiki

+integrator or wiki software author. Certainly the person would need to

+be interested in human languages and translation. They should at least

+be minimally familiar with what Tor is; but they would not have to interact

+with the software, only the documentation and the website.

+</li>

+

+<li>

+<b>Better Debian/Ubuntu Packaging for Tor+Vidalia</b>

+<br />

+Priority: <i>High</i>

+<br />

+Effort Level: <i>Medium</i>

+<br />

+Skill Level: <i>Medium</i>

+<br />

+Likely Mentors: <i>Peter, Matt</i>

+<br />

+Applications as of 1 Apr 00:00 UTC: <i>1</i>

+<br />

+Vidalia currently doesn't play nicely on Debian and Ubuntu with the

+default Tor packages. The current Tor packages automatically start Tor

+as a daemon running as the debian-tor user and (sensibly) do not have a

+<a href="<svnsandbox>doc/spec/control-spec.txt">ControlPort</a> defined

+in the default torrc. Consequently, Vidalia will try

+to start its own Tor process since it could not connect to the existing

+Tor, and Vidalia's Tor process will then exit with an error message

+the user likely doesn't understand since Tor cannot bind its listening

+ports — they're already in use by the original Tor daemon.

+<br />

+The current solution involves either telling the user to stop the

+existing Tor daemon and let Vidalia start its own Tor process, or

+explaining to the user how to set a control port and password in their

+torrc. A better solution on Debian would be to use Tor's ControlSocket,

+which allows Vidalia to talk to Tor via a Unix domain socket, and could

+possibly be enabled by default in Tor's Debian packages. Vidalia can

+then authenticate to Tor using filesystem-based (cookie) authentication

+if the user running Vidalia is also in the debian-tor group.

+<br />

+This project will first involve adding support for Tor's ControlSocket

+to Vidalia. The student will then develop and test Debian and Ubuntu

+packages for Vidalia that conform to Debian's packaging standards and

+make sure they work well with the existing Tor packages. We can also

+set up an apt repository to host the new Vidalia packages.

+<br />

+The next challenge would be to find an intuitive usable way for Vidalia

+to be able to change Tor's configuration (torrc) even though it is

+located in <code>/etc/tor/torrc</code> and thus immutable. The best

+idea we've come up with so far is to feed Tor a new configuration via

+the ControlSocket when Vidalia starts, but that's bad because Tor starts

+each boot with a different configuration than the user wants. The second

+best idea

+we've come up with is for Vidalia to write out a temporary torrc file

+and ask the user to manually move it to <code>/etc/tor/torrc</code>,

+but that's bad because users shouldn't have to mess with files directly.

+<br />

+A student undertaking this project should have prior knowledge of

+Debian package management and some C++ development experience. Previous

+experience with Qt is helpful, but not required.

+</li>

+

+<li>

+<b>Improving Tor's ability to resist censorship</b>

+<br />

+Priority: <i>High</i>

+<br />

+Effort Level: <i>High</i>

+<br />

+Skill Level: <i>High</i>

+<br />

+Likely Mentors: <i>Nick</i>

+<br />

+The Tor 0.2.0.x series makes <a

+href="<svnsandbox>doc/design-paper/blocking.html">significant

+improvements</a> in resisting national and organizational censorship.

+But Tor still needs better mechanisms for some parts of its

+anti-censorship design.  For example, current Tors can only listen on a

+single address/port combination at a time.  There's

+<a href="<svnsandbox>doc/spec/proposals/118-multiple-orports.txt">a

+proposal to address this limitation</a> and allow clients to connect

+to any given Tor on multiple addresses and ports, but it needs more

+work.  Another anti-censorship project (far more difficult) is to try

+to make Tor more scanning-resistant.  Right now, an adversary can identify

+<a href="<svnsandbox>doc/spec/proposals/125-bridges.txt">Tor bridges</a>

+just by trying to connect to them, following the Tor protocol, and

+seeing if they respond.  To solve this, bridges could

+<a href="<svnsandbox>doc/design-paper/blocking.html#tth_sEc9.3">act like

+webservers</a> (HTTP or HTTPS) when contacted by port-scanning tools,

+and not act like bridges until the user provides a bridge-specific key.

+<br />

+This project involves a lot of research and design. One of the big

+challenges will be identifying and crafting approaches that can still

+resist an adversary even after the adversary knows the design, and

+then trading off censorship resistance with usability and robustness.

+</li>

+

+<li>

+<b>Tor/Polipo/Vidalia Auto-Update Framework</b>

+<br />

+Priority: <i>Medium</i>

+<br />

+Effort Level: <i>High</i>

+<br />

+Skill Level: <i>High</i>

+<br />

+Likely Mentors: <i>Matt, Jacob</i>

+<br />

+We're in need of a good authenticated-update framework.

+Vidalia already has the ability to notice when the user is running an

+outdated or unrecommended version of Tor, using signed statements inside

+the Tor directory information. Currently, Vidalia simply pops

+up a little message box that lets the user know they should manually

+upgrade. The goal of this project would be to extend Vidalia with the

+ability to also fetch and install the updated Tor software for the

+user. We should do the fetches via Tor when possible, but also fall back

+to direct fetches in a smart way. Time permitting, we would also like

+to be able to update other

+applications included in the bundled installers, such as Polipo and

+Vidalia itself.

+<br />

+To complete this project, the student will first need to first investigate

+the existing auto-update frameworks (e.g., Sparkle on OS X) to evaluate

+their strengths, weaknesses, security properties, and ability to be

+integrated into Vidalia. If none are found to be suitable, the student

+will design their own auto-update framework, document the design, and

+then discuss the design with other developers to assess any security

+issues. The student will then implement their framework (or integrate

+an existing one) and test it.

+<br />

+A student undertaking this project should have good C++ development

+experience. Previous experience with Qt is helpful, but not required. The

+student should also have a good understanding of common security

+practices, such as package signature verification. Good writing ability

+is also important for this project, since a vital step of the project

+will be producing a design document for others to review and discuss

+with the student prior to implementation.

+</li>

+

+<li>

+<b>An Improved and More Usable Network Map in Vidalia</b>

+<br />

+Priority: <i>Medium</i>

+<br />

+Effort Level: <i>Medium</i>

+<br />

+Skill Level: <i>Medium to High</i>

+<br />

+Likely Mentors: <i>Matt</i>

+<br />

+One of Vidalia's existing features is a network map that shows the user

+the approximate geographic location of relays in the Tor network and

+plots the paths the user's traffic takes as it is tunneled through the

+Tor network. The map is currently not very interactive and has rather

+poor graphics. Instead, we would like to leverage KDE's Marble widget

+that gives us a better quality map and enables improved interactivity,

+such as allowing the user to click on individual relays or circuits to

+display additional information. We might also consider adding the ability

+for users to click on a particular relay or a country containing one or

+more Tor exit relays and say, "I want my connections to foo.com to exit

+from here."

+<br />

+This project will first involve the student getting familiar with Vidalia

+and the Marble widget's API. The student will then integrate the widget

+into Vidalia and customize Marble to be better suited for our application,

+such as making circuits clickable, storing cached map data in Vidalia's

+own data directory, and customizing some of the widget's dialogs.

+<br />

+A student undertaking this project should have good C++ development

+experience. Previous experience with Qt and CMake is helpful, but not

+required.

+</li>

+

+<li>

+<b>Tor Controller Status Event Interface</b>

+<br />

+Priority: <i>Medium</i>

+<br />

+Effort Level: <i>Medium</i>

+<br />

+Skill Level: <i>Medium</i>

+<br />

+Likely Mentors: <i>Matt, Roger</i>

+<br />

+There are a number of status changes inside Tor of which the user may need

+to be informed. For example, if the user is trying to set up his Tor as a

+relay and Tor decides that its ports are not reachable from outside

+the user's network, we should alert the user. Currently, all the user

+gets is a couple log messages in Vidalia's 'message log' window, which they

+likely never see since they don't receive a notification that something

+has gone wrong. Even if the user does actually look at the message log,

+most of the messages make little sense to the novice user.

+<br />

+Tor has the ability to inform Vidalia of many such status changes, and

+we recently implemented support for a couple of these events. Still,

+there are many more status events the user should be informed of and we

+need a better UI for actually displaying them to the user.

+<br />

+The goal of this project then is to design and implement a UI for

+displaying Tor status events to the user. For example, we might put a

+little badge on Vidalia's tray icon that alerts the user to new status

+events they should look at. Double-clicking the icon could bring up a

+dialog that summarizes recent status events in simple terms and maybe

+suggests a remedy for any negative events if they can be corrected by

+the user. Of course, this is just an example and the student is free to

+suggest another approach.

+<br />

+A student undertaking this project should have good UI design and layout

+and some C++ development experience. Previous experience with Qt and

+Qt's Designer will be very helpful, but are not required. Some

+English writing ability will also be useful, since this project will

+likely involve writing small amounts of help documentation that should

+be understandable by non-technical users. Bonus points for some graphic

+design/Photoshop fu, since we might want/need some shiny new icons too.

+</li>

+

+<li>

+<b>Improvements on our active browser configuration tester</b> -

+<a href="https://check.torproject.org/">https://check.torproject.org/</a>

+<br />

+Priority: <i>Medium</i>

+<br />

+Effort Level: <i>Low</i>

+<br />

+Skill Level: <i>Low to Medium</i>

+<br />

+Likely Mentors: <i>Jacob, Steven</i>

+<br />

+Applications as of 1 Apr 00:00 UTC: <i>1</i>

+<br />

+We currently have a functional web page to detect if Tor is working. It

+has a few places where it falls short. It requires improvements with

+regard to default languages and functionality. It currently only responds

+in English. In addition, it is a hack of a perl script that should have

+never seen the light of day. It should probably be rewritten in python

+with multi-lingual support in mind. It currently uses the <a

+href="http://exitlist.torproject.org/">Tor DNS exit list</a>

+and should continue to do so in the future. It currently result in certain

+false positives and these should be discovered, documented, and fixed

+where possible. Anyone working on this project should be interested in

+DNS, basic perl or preferably python programming skills, and will have

+to interact minimally with Tor to test their code.

+<br />

+If you want to make the project more exciting

+and involve more design and coding, take a look at <a

+href="<svnsandbox>doc/spec/proposals/131-verify-tor-usage.txt">proposal

+131-verify-tor-usage.txt</a>.

+</li>

+

+<li>

+<b>Improvements on our DNS Exit List service</b> -

+<a href="http://exitlist.torproject.org/">http://exitlist.torproject.org/</a>

+<br />

+Priority: <i>Medium</i>

+<br />

+Effort Level: <i>Low</i>

+<br />

+Skill Level: <i>Low</i>

+<br />

+Likely Mentors: <i>Jacob, Tup</i>

+<br />

+The <a href="http://p56soo2ibjkx23xo.onion/">exitlist software</a>

+is written by our fabulous anonymous

+contributer Tup. It's a DNS server written in Haskell that supports part of our <a

+href="https://www.torproject.org/svn/trunk/doc/contrib/torel-design.txt">exitlist

+design document</a>. Currently, it is functional and it is used by

+check.torproject.org and other users. The issues that are outstanding

+are mostly aesthetic. This wonderful service could use a much better

+website using the common Tor theme. It would be best served with better

+documentation for common services that use an RBL. It could use more

+publicity. A person working on this project should be interested in DNS,

+basic RBL configuration for popular services, and writing documentation.

+The person would require minimal Tor interaction — testing their

+own documentation at the very least. Furthermore, it would be useful

+if they were interested in Haskell and wanted to implement more of the

+torel-design.txt suggestions.

+</li>

+

+<li>

+<b>Testing integration of Tor with web browsers for our end users</b>

+<br />

+Priority: <i>Medium</i>

+<br />

+Effort Level: <i>Medium</i>

+<br />

+Skill Level: <i>Medium</i>

+<br />

+Likely Mentors: <i>Jacob, Mike, Greg</i>

+<br />

+Applications as of 1 Apr 00:00 UTC: <i>1</i>

+<br />

+The Tor project currently lacks a solid test suite to ensure that a

+user has a properly and safely configured web browser. It should test for as

+many known issues as possible. It should attempt to decloak the

+user in any way possible. Two current webpages that track these

+kinds of issues are run by Greg Fleischer and HD Moore. Greg keeps a nice <a

+href="http://pseudo-flaw.net/tor/torbutton/">list of issues along

+with their proof of concept code, bug issues, etc</a>. HD Moore runs

+the <a href="http://metasploit.com/research/projects/decloak/">metasploit

+decloak website</a>. A student interested in defending Tor could start

+by collecting as many workable and known methods for decloaking a

+Tor user. (<a href="https://torcheck.xenobite.eu/">This page</a> may

+be helpful as a start.) The student should be familiar with the common

+pitfalls but

+possibly have new methods in mind for implementing decloaking issues. The

+website should ensure that it tells a user what their problem is. It

+should help them to fix the problem or direct them to the proper support

+channels. The student should be closely familiar with using Tor and how

+to prevent Tor information leakage.

+</li>

+

+<li>

+<b>Libevent and Tor integration improvements</b>

+<br />

+Priority: <i>Medium</i>

+<br />

+Effort Level: <i>High</i>

+<br />

+Skill Level: <i>Medium to High</i>

+<br />

+Likely Mentors: <i>Nick</i>

+<br />

+Tor should make better use of the more recent features of Niels

+Provos's <a href="http://monkey.org/~provos/libevent/">Libevent</a>

+library.  Tor already uses Libevent for its low-level asynchronous IO

+calls, and could also use Libevent's increasingly good implementations

+of network buffers and of HTTP.  This wouldn't be simply a matter of

+replacing Tor's internal calls with calls to Libevent: instead, we'll

+need to refactor Tor to use Libevent calls that do not follow the

+same models as Tor's existing backends. Also, we'll need to add

+missing functionality to Libevent as needed — most difficult likely

+will be adding OpenSSL support on top of Libevent's buffer abstraction.

+Also tricky will be adding rate-limiting to Libevent.

+</li>

+

+<li>

+<b>Tuneup Tor!</b>

+<br />

+Priority: <i>Medium</i>

+<br />

+Effort Level: <i>Medium</i>

+<br />

+Skill Level: <i>Medium to High</i>

+<br />

+Likely Mentors: <i>Nick, Roger, Mike</i>

+<br />

+Right now, Tor relays measure and report their own bandwidth, and Tor

+clients choose which relays to use in part based on that bandwidth.

+This approach is vulnerable to

+<a href="http://freehaven.net/anonbib/#bauer:wpes2007">attacks where

+relays lie about their bandwidth</a>;

+to address this, Tor currently caps the maximum bandwidth

+it's willing to believe any relay provides.  This is a limited fix, and

+a waste of bandwidth capacity to boot.  Instead,

+Tor should possibly measure bandwidth in a more distributed way, perhaps

+as described in the

+<a href="http://freehaven.net/anonbib/author.html#snader08">"A Tune-up for

+Tor"</a> paper

+by Snader and Borisov. A student could use current testing code to

+double-check this paper's findings and verify the extent to which they

+dovetail with Tor as deployed in the wild, and determine good ways to

+incorporate them into their suggestions Tor network without adding too

+much communications overhead between relays and directory

+authorities.

+</li>

+

+<!--

+<li>

+<b>Improving the Tor QA process: Continuous Integration for Windows builds</b>

+<br />

+Priority: <i>High</i>

+<br />

+Effort Level: <i>Medium</i>

+<br />

+Skill Level: <i>Medium</i>

+<br />

+Likely Mentors: <i>Jacob, Andrew</i>

+<br />

+It would be useful to have automated build processes for Windows and

+probably other platforms. The purpose of having a continuous integration

+build environment is to ensure that Windows isn't left behind for any of

+the software projects used in the Tor project or its accompanying.<br />

+Buildbot may be a good choice for this as it appears to support all of

+the platforms Tor does. See the

+<a href="http://en.wikipedia.org/wiki/BuildBot">wikipedia entry for

+buildbot</a>.<br />

+There may be better options and the person undertaking this task should

+evaluate other options. Any person working on this automatic build

+process should have experience or be willing to learn how to build all

+of the respective Tor related code bases from scratch. Furthermore, the

+person should have some experience building software in Windows

+environments as this is the target audience we want to ensure we do not

+leave behind. It would require close work with the Tor source code but

+probably only in the form of building, not authoring.<br />

+Additionally, we need to automate our performance testing for all platforms.

+We've got buildbot (except on Windows — as noted above) to automate

+our regular integration and compile testing already,

+but we need to get our network simulation tests (as built in torflow)

+updated for more recent versions of Tor, and designed to launch a test

+network either on a single machine, or across several, so we can test

+changes in performance on machines in different roles automatically.

+</li>

+-->