commit 3ddd63efa5296a221daa8a295280b37b2546e2bf Author: Damian Johnson atagar@torproject.org Date: Mon Feb 29 09:07:37 2016 -0800

Drop projects/mentors we haven't heard from

Dropping the folks we haven't heard from with regard to GSoC. For projects where they're the last names remaining dropping the project itself too. --- getinvolved/en/volunteer.wml | 307 +------------------------------------------ 1 file changed, 3 insertions(+), 304 deletions(-)

diff --git a/getinvolved/en/volunteer.wml b/getinvolved/en/volunteer.wml index aa53608..0b6d497 100644 --- a/getinvolved/en/volunteer.wml +++ b/getinvolved/en/volunteer.wml @@ -416,11 +416,7 @@ meetings around the world.</li>

<p> <b>Project Ideas:</b><br /> - <i><a href="#torCleanup">Tor Codebase Cleanup</a></i><br /> - <i><a href="#improveTorTestCoverage">Improve test coverage in Tor</a></i><br /> - <i><a href="#useMoreCores">Have the Tor daemon use more cores</a></i><br /> - <i><a href="#improveHiddenServices">Help improve Tor hidden services</a></i><br /> - <i><a href="#improvedDnsSupport">Improved DNS support for Tor</a></i> + <i><a href="#improveHiddenServices">Help improve Tor hidden services</a></i> </p>

<a id="project-torbrowser"></a> @@ -558,12 +554,6 @@ meetings around the world.</li> block Tor. This has both a C and python implementation. </p>

- <p> - <b>Project Ideas:</b><br /> - <i><a href="https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports#Helpneeded">Various coding tasks</a></i> <br/> - <i><a href="#betterPluggableTransports">Build Better Pluggable Transports</a></i> - </p> - <a id="project-flash-proxy"></a> <h3><a href="https://crypto.stanford.edu/flashproxy/">Flash Proxy</a> (<a href="https://gitweb.torproject.org/flashproxy.git">code</a>, <a @@ -795,11 +785,6 @@ meetings around the world.</li> content. </p>

- <p> - <b>Project Ideas:</b><br /> - <i><a href="#ooniprobePcapsSupport">Add Support for Reporting Pcaps to OoniBackend and OoniProbe</a></i> - </p> - <a id="project-torps"></a> <h3>TorPS</a> (<a href="https://github.com/torps/torps">code</a>)</h3>

@@ -866,125 +851,13 @@ meetings around the world.</li>

<ol>

- <a id="torCleanup"></a> - <li> - <b>Tor Codebase Cleanup</b> - <br> - Language: <i>C</i> - <br> - Likely Mentors: <i>David (dgoulet)</i> - <br><br> - <p> - The Tor code is more than 10 years old in places, and we haven't always had - enough time or wisdom to write things as well as we could have. Our unit - test coverage is shamefully low, and the dependency graph of our modules is - shamefully convoluted . We could use refactoring and unit tests! Please - look through the Tor source code and look for ugly or tricky code or - dependencies -- the uglier and trickier the better -- and think about how - you could make the code look better, read better, and (subject to testing) - work better. - </p> - - <p> - If this is for a fun side-project, it would be great for you to work on - anything that can be made better and more tested. For an internship-level - position, we'd hope that you could find a number of particularly tricky or - knotty piece of the code to clean up, and aim for resolving the ugliest - problems, not necessarily the easiest. - </p> - - <p> - For a big project here, it would be great to pick one of the major - "submodules" of Tor -- path selection, node discovery, directory authority - operations, directory service -- and refactor its interface completely, to - minify and codify its points of contact with the rest of Tor. - </p> - - <p> - <b>As part of your application for this project please identify one of the - thorniest Tor functions and submit a patch refactoring it to be better. If - you find this to be difficult then this likely isn't the project for - you.</b> - </p> - </li> - - <a id="betterPluggableTransports"></a> - <li> - <b>Build Better Pluggable Transports</b> - <br> - Language: <i>C, Python</i> - <br> - Likely Mentors: <i>Ximin (infinity0)</i> - <br><br> - <p> - For Tor users in censored countries, we have a <a - href="<page docs/pluggable-transports>"> - pluggable transports</a> framework that uses external programs to bypass - censorship in different ways. Each of these have their own strengths and - weaknesses. - </p> - - <p> - We have deployed <a - href="<page projects/obfsproxy>">obfsproxy</a>, - <a href="http://crypto.stanford.edu/flashproxy/">flashproxy</a>, - <a href="http://www.cs.kau.se/philwint/scramblesuit/">scramblesuit</a>, - <a href="https://trac.torproject.org/projects/tor/wiki/doc/meek">meek</a>, - and <a href="https://fteproxy.org/about">FTE</a> bridges into the main - Tor Browser.</a> - </p> - - <p> - There are several possible directions for this project. Ideas include: - <ol> - <li>Address gaps or weaknesses in our existing pluggable transports - <ul> - <li>Flashproxy: Add WebRTC support to traverse NATs.</li> - <li>Flashproxy: Improve the facilitator's resistance against DoS - and poisoning attacks.</li> - </ul> - </li> - <li>Finish and release our pluggable transport combiner, that chains - several transports together to take advantage of orthogonal types of - blocking resistance.</li> - <li>Improve the UX for selecting the appropriate pluggable transport in - the new Tor Browser, whilst maintaining user security.</li> - <li>Implement a new pluggable transport that resists blocking in a - novel way. - <ul> - <li>Impersonate a voice-over-IP protocol</li> - <li>Impersonate HTTP <a - href="http://www.cs.utexas.edu/~amir/papers/parrot.pdf%22%3Esufficiently - well</a> that traffic will go through a HTTP-only proxy</li> - <li>Implement <a - href="http://cacr.uwaterloo.ca/techreports/2011/cacr2011-21.pdf%22%3Escanning - resistance</a></li> - </ul> - </li> - </ol> - </p> - - <p> - Applicants should be familiar with asynchronous/reactive programming, in - particular the <a href="https://twistedmatrix.com/">Twisted framework</a> - or something related. Most of the existing code is written in Python, with - some parts in JavaScript and Go, so you should know at least one of these. - You are invited to talk to us and ask questions, via our mailing lists - or IRC. <b>As part of your application, please contribute a patch that - implements a small feature or fixes a bug related to this area, e.g. <a - href="https://trac.torproject.org/projects/tor/query?status=!closed&component=...</a>, - <a href="https://trac.torproject.org/projects/tor/query?status=!closed&component=Obfsproxy">2</a>, - <a href="https://trac.torproject.org/projects/tor/query?status=!closed&component=Flashproxy">3</a>. - </b> - </p> - <a id="makeTorbirdyBetter"></a> <li> <b>Make TorBirdy Better</b> <br> Language: <i>JavaScript, C++</i> <br> - Likely Mentors: <i>Sukhbir Singh (sukhe), Jacob Appelbaum (ioerror)</i> + Likely Mentors: <i>Sukhbir Singh (sukhe)</i> <br><br> <p> TorBirdy is an extension that configures Thunderbird to make connections over @@ -1021,152 +894,13 @@ You may contact the mentors on IRC for more information. (sukhe on #tor-dev, #to </p> </li>

- <a id="ooniprobePcapsSupport"></a> - <li> - <b>Add Support for Reporting Pcaps to OoniBackend and OoniProbe</b> - <br> - Language: <i>Python</i> - <br> - Likely Mentors: <i>Arturo (hellais)</i> - <br><br> - <p> -The feature should also add support for including only packet capture data that -is relevant to the test being run. This means that the pcap should not contain -all the data sniffed on the users machine, but only that which was generated -and intended to be received by ooniprobe. - </p> - - <p> -This can probably be implemented by setting up a tun/tap device and routing all -the ooniprobe traffic through it and only capturing data sent and received from -that device. The task for the student will also be that of doing research into -what are possible strategies for doing this. <b><a -href="https://trac.torproject.org/projects/tor/ticket/7416%22%3EFor more -information see ticket 7416.</a></b> - </p> - </li> - - <a id="improveTorTestCoverage"></a> - <li> - <b>Improve test coverage in Tor</b> - <br> - Language: <i>C, Python</i> - <br> - Likely Mentors: <i>David (dgoulet)</i> - <br><br> - <p> -Right now, our unit test coverage with the tests we ship is around 30% --- only 30% of the executable lines in our source are reached by the -unit tests. Improving this test coverage could make Tor development -much more reliable. - </p> - - <p> -So we need better unit tests, and we need better integration tests too. - </p> - - <p> -Improving unit tests would involve refactoring functions to be more -testable, and writing a bunch of unit tests. - </p> - - <p> -Improving integration tests would involve refactoring and improving -the "chutney" program that launches a test tor network, and writing a -bunch of tests to see what works and what doesn't work on such a -network. It could also involve writing tests using the library "<a -href="https://stem.torproject.org/%22%3Estem</a>" to script individual clients on a -Chutney network. - </p> - - <p> -To get a feel for how testing works in Tor today, download Tor and -Chutney, and make sure you can build Tor and use Chutney. See how the -unit tests work by skimming some of the test code in the src/test -subdirectory. Try computing test coverage (according to the -instructions in the doc/HACKING file. - </p> - - <p> -Also, have a look at the one current integration test that works on -chutney today: it is a shell script distributed with Tor as -src/test/test-tor-network.sh . We probably don't want to have all of -our integration tests be written as shell scripts, but it's interesting -to see how one works. - </p> - - <p> -If working on designs for an improved or refactored Chutney, watch out for <a -href="http://www.joelonsoftware.com/articles/fog0000000018.html%22%3E%22archicture -astronautics"</a>: while it's important that we have a well-designed and -maintainable Chutney architecture, it wouldn't be very useful if a good -architecture were the <em>only</em> outcome here: we need tests too. - </p> - - <p> -As part of the application process, please contribute a patch that makes -a non-trivial improvement to chutney, and/or include a new test for some -interesting Tor function. (Please pick a function that isn't completely -easy to test.) - </p> - </li> - - <a id="useMoreCores"></a> - <li> - <b>Have the Tor daemon use more cores</b> - <br> - Language: <i>C</i> - <br> - Likely Mentors: <i>David (dgoulet)</i> - <br><br> - <p> -Right now, if you run a busy Tor server on a multicore computer, most of -the cores are mostly unused. We have a "cpuworker" mechanism to move -expensive computations into worker threads, but that mechanism is -currently only used for a small fraction of our cryptography. Moving -more work into the worker threads could improve performance immensely. - </p> - - <p> -So it would be great to parallelize our cryptography more in order to -better handle more cores. See -<a href="https://trac.torproject.org/projects/tor/wiki/org/projects/Tor/MultithreadedCrypto">MultithreadedCrypto</a> -for some background info, and -<a href="https://trac.torproject.org/projects/tor/ticket/7572">ticket 7572</a> for some subtickets -on our tracker. - </p> - - <p> -(If you're reading through the code to see how it works today, you will -also want to have a look at the new implementation for cpuworkers -described in <a href="https://trac.torproject.org/projects/tor/ticket/9682">9682</a>.) - </p> - - <p> -Completing the implementation of ticket #7572 --which would move our -circuit crypto onto separate threads-- could be a good summer project. -Alternatively, moving all of the signature generation and verification -code onto the cpuworkers could be fun. In either case, you will have -some important architectural decisions to make about how to minimize -shared data between the main thread and the workers, how to avoid -race conditions between them, and how to test it all to make sure it has -no hidden failure cases. - </p> - - <p> -As part of the application process for this project, please contribute a -nontrivial patch to Tor -- ideally, one that will affect some part of -the codebase that you want to work on. - </p> - </li> - <a id="improveHiddenServices"></a> <li> <b>Help improve Tor hidden services</b> <br> Language: <i>C</i> <br> - Likely Mentors: <i>David (dgoulet), George (asn)</i> + Likely Mentors: <i>George (asn)</i> <br><br> <p> We're working on a revamp of the entire Tor hidden service design to @@ -1196,41 +930,6 @@ the codebase that you want to work on. </p> </li>

- <a id="improvedDnsSupport"></a> - <li> - <b>Improved DNS support for Tor</b> - <br> - Language: <i>C</i> - <br> - Likely Mentors: <i>David (dgoulet)</i> - <br><br> - <p> -Right now, you can only use Tor's DNS support to look up IPv4 and IPv6 -addresses, and to fetch PTR records. But DNS can do so much more! - </p> - - <p> -<a -href="https://gitweb.torproject.org/torspec.git/tree/proposals/219-expanded-dns.tx... -219</a> describes some new cell types that Tor could use to support -more types of DNS over Tor. - </p> - - <p> -To see how Tor implements its existing DNS lookups, start by tracing the -the connection_exit_begin_resolve() function in src/or/connection_edge.c , -and see how we pass these requests downwards through src/or/dns.c to the -underlying resolver. It's not too complicated, but there are some -tricky parts to understand. - </p> - - <p> -As part of the application process for this project, please contribute a -nontrivial patch to Tor -- ideally, one that will affect some part of -the codebase that you want to work on. - </p> - </li> - <a id="exitmap_improvements"></a> <li> <b>Exitmap Improvements</b>