[tor-commits] r25882: {website} Adding revised tor project ideas Nick has written four shiny (website/trunk/getinvolved/en)
Damian Johnson
atagar1 at gmail.com
Tue Nov 13 16:45:51 UTC 2012
Author: atagar
Date: 2012-11-13 16:45:50 +0000 (Tue, 13 Nov 2012)
New Revision: 25882
Modified:
website/trunk/getinvolved/en/volunteer.wml
Log:
Adding revised tor project ideas
Nick has written four shiny, new project ideas (mmmm, shiny...).
Modified: website/trunk/getinvolved/en/volunteer.wml
===================================================================
--- website/trunk/getinvolved/en/volunteer.wml 2012-11-13 16:22:30 UTC (rev 25881)
+++ website/trunk/getinvolved/en/volunteer.wml 2012-11-13 16:45:50 UTC (rev 25882)
@@ -358,15 +358,13 @@
extents, but the chief architects are Nick Mathewson and Roger Dingledine.
</p>
- <!--
<p>
<b>Project Ideas:</b><br />
- <i><a href="#resistCensorship">Improving Tor's ability to resist
- censorship</a></i><br />
- <i><a href="#user-space-transport">Integrating Tor with user-space
- transport protocol libraries</a></i>
+ <i><a href="#limitCapabilities">Run With Limited Capabilities</a></i><br />
+ <i><a href="#torCleanup">Tor Codebase Cleanup</a></i><br />
+ <i><a href="#httpsImersonation">HTTPS Server Impersonation</a></i><br />
+ <i><a href="#chutneyExpansion">Make Chutney Do More, More Reliably</a></i>
</p>
- -->
<a id="project-jtor"></a>
<h3><a href="https://github.com/brl/JTor/wiki">JTor</a> (<a
@@ -975,6 +973,126 @@
</li>
-->
+ <a id="limitCapabilities"></a>
+ <li>
+ <b>Run With Limited Capabilities</b>
+ <br>
+ Priority: <i>Medium to High</i>
+ <br>
+ Effort Level: <i>Medium to High</i>
+ <br>
+ Skill Level: <i>High</i>
+ <br>
+ Likely Mentors: <i>Nick (nickm)</i>
+ <p>
+ Many modern operating systems give a running program the ability to drop
+ capabilities that it no longer needs, and other ways for a program to run
+ pieces of itself in a sandbox with diminished privileges.
+ </p>
+
+ <p>
+ We'd like to do this with Tor, to improve its resistance to attacks. The
+ easiest areas to address would be on systems like <a
+ href="https://lwn.net/Articles/475361/">recent Linux kernels</a> that make
+ it easy to drop or restrict the set of syscalls that a program can invoke.
+ That's a great project, but probably not big enough for an internship just
+ on its own. For that, we'd want to make progress on at least multiple
+ platforms, or look into refactoring Tor into pieces that need more
+ privileges and pieces that don't with an eye towards sandboxing them
+ differently.
+ </p>
+
+ <p>
+ See tickets <a href="https://trac.torproject.org/7005">#7005</a> and <a
+ href="https://trac.torproject.org/5219">#5219</a>, and their descendants,
+ for more information.
+ </p>
+ </li>
+
+ <a id="torCleanup"></a>
+ <li>
+ <b>Tor Codebase Cleanup</b>
+ <br>
+ Priority: <i>Medium to High</i>
+ <br>
+ Effort Level: <i>Low to High, depending on subproject chosen</i>
+ <br>
+ Skill Level: <i>Medium to High</i>
+ <br>
+ Likely Mentors: <i>Nick (nickm)</i>
+ <p>
+ The Tor code is almost 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>
+ </li>
+
+ <a id="httpsImersonation"></a>
+ <li>
+ <b>HTTPS Server Impersonation</b>
+ <br>
+ Priority: <i>Medium</i>
+ <br>
+ Effort Level: <i>Medium to High</i>
+ <br>
+ Skill Level: <i>Medium to High</i>
+ <br>
+ Likely Mentors: <i>Nick (nickm)</i>
+ <p>
+ We have an open proposal for a way to make Tor bridges avoid censorship by
+ impersonating an HTTPS server. Specifically, we need to hack some popular
+ SSL "reverse proxy" (your choice) so that it relays regular web connections
+ to an HTTP server, but certain connections to a local Tor process. <a
+ href="https://gitweb.torproject.org/torspec.git/blob_plain/HEAD:/proposals/203-https-frontend.txt">Proposal
+ 203</a> has a general design sketch.
+ </p>
+ </li>
+
+ <a id="chutneyExpansion"></a>
+ <li>
+ <b>Make Chutney Do More, More Reliably</b>
+ <br>
+ Priority: <i>Medium</i>
+ <br>
+ Effort Level: <i>Medium to High, depending on scope of project</i>
+ <br>
+ Skill Level: <i>Medium</i>
+ <br>
+ Likely Mentors: <i>Nick (nickm)</i>
+ <p>
+ We have a little Python tool called <a
+ href="https://gitweb.torproject.org/nickm/chutney.git">Chutney</a> for
+ making small local test networks. It's small, not widely used, and not as
+ automated as it could be.
+ </p>
+
+ <p>
+ It would be great to see chutney extended and a set of supporting tests
+ built to the point where we could use Chutney to exercise various Tor
+ features as an automated integration test.
+ </p>
+ </li>
+
<a id="stemUsability"></a>
<li>
<b>Stem Usability Improvements</b>
More information about the tor-commits
mailing list