tor-webwml.git

@@ -24,7 +24,7 @@ a fuzzer for Tor; mentored by Roger.</dd>

 Improving Tor Path Selection (<a

 href="https://svn.torproject.org/cgi-bin/viewvc.cgi/torflow/branches/gsoc2008/">svn</a>)

 and <a

-href="<gitblob>doc/spec/proposals/151-path-selection-improvements.txt">proposal

+href="<specblob>proposals/151-path-selection-improvements.txt">proposal

 151</a> as part of Google Summer of Code 2008.</dd>

 <dt>Bram Cohen</dt><dd>Helped design our congestion control mechanisms,

 in Tor's early days.</dd>

@@ -105,7 +105,7 @@

           press, and general support.</dd>

           <dt>Dr. Karsten Loesing, Researcher and Developer</dt>

           <dd>Worked during the 2007 Google Summer of Code on <a

-          href="<gitblob>doc/spec/proposals/114-distributed-storage.txt">distributing

+          href="<specblob>proposals/114-distributed-storage.txt">distributing

           and securing the publishing and fetching of hidden

           service descriptors</a>. Currently the primary

           researcher for our National Science Foundation grant

@@ -192,7 +192,7 @@

     <p>

     If you would like to learn more about our bridge

     design from a technical standpoint, please read the <a

-    href="<gitblob>doc/spec/bridges-spec.txt">Tor bridges

+    href="<specblob>bridges-spec.txt">Tor bridges

     specification</a>. If you're interested in running an unpublished bridge

     or other non-standard uses, please do read the specification.

     </p>

@@ -137,9 +137,9 @@

     <li>

     Learn about the <a

-    href="<gitblob>doc/spec/proposals/001-process.txt">Tor

+    href="<specblob>proposals/001-process.txt">Tor

     proposal process for changing our design</a>, and look over the <a

-    href="<gittree>doc/spec/proposals">existing proposals</a>.

+    href="<spectree>proposals">existing proposals</a>.

     </li>

     <li>

@@ -210,25 +210,25 @@

     <li>The <b>specifications</b> aim to give

     developers enough information to build a compatible version of Tor:

     <ul>

-    <li><a href="<gitblob>doc/spec/tor-spec.txt">Main Tor specification</a></li>

-    <li><a href="<gitblob>doc/spec/dir-spec.txt">Tor

+    <li><a href="<specblob>tor-spec.txt">Main Tor specification</a></li>

+    <li><a href="<specblob>dir-spec.txt">Tor

     version 3 directory server specification</a> (and older <a

-    href="<gitblob>doc/spec/dir-spec-v1.txt">version 1</a> and <a

-    href="<gitblob>doc/spec/dir-spec-v2.txt">version 2</a> directory

+    href="<specblob>dir-spec-v1.txt">version 1</a> and <a

+    href="<specblob>dir-spec-v2.txt">version 2</a> directory

     specifications)</li>

-    <li><a href="<gitblob>doc/spec/control-spec.txt">Tor control protocol

+    <li><a href="<specblob>control-spec.txt">Tor control protocol

     specification</a></li>

-    <li><a href="<gitblob>doc/spec/rend-spec.txt">Tor rendezvous

+    <li><a href="<specblob>rend-spec.txt">Tor rendezvous

     specification</a></li>

-    <li><a href="<gitblob>doc/spec/path-spec.txt">Tor path selection

+    <li><a href="<specblob>path-spec.txt">Tor path selection

     specification</a></li>

-    <li><a href="<gitblob>doc/spec/address-spec.txt">Special hostnames in

+    <li><a href="<specblob>address-spec.txt">Special hostnames in

     Tor</a></li>

-    <li><a href="<gitblob>doc/spec/socks-extensions.txt">Tor's SOCKS support

+    <li><a href="<specblob>socks-extensions.txt">Tor's SOCKS support

     and extensions</a></li>

-    <li><a href="<gitblob>doc/spec/version-spec.txt">How Tor version numbers

+    <li><a href="<specblob>version-spec.txt">How Tor version numbers

     work</a></li>

-    <li><a href="<gittree>doc/spec/proposals">In-progress drafts of

+    <li><a href="<spectree>proposals">In-progress drafts of

     new specifications and proposed changes</a></li>

     </ul></li>

@@ -1461,7 +1461,7 @@ the same geographic location.

     have the right keys for them? Each relay has a long-term public signing

     key called the "identity key". Each directory authority additionally has a

     "directory signing key". The directory authorities <a

-    href="<gitblob>doc/spec/dir-spec.txt">provide a signed list</a>

+    href="<specblob>dir-spec.txt">provide a signed list</a>

     of all the known relays, and in that list are a set of certificates from

     each relay (self-signed by their identity key) specifying their keys,

     locations, exit policies, and so on. So unless the adversary can control

@@ -665,7 +665,7 @@ meetings around the world.</li>

     <p>If you want to get more into the guts of Tor itself (C), a more minor problem

     we should address is that current Tors can only listen on a single

     address/port combination at a time. There's

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

+    <a href="<specblob>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.</p>

@@ -1096,7 +1096,7 @@ meetings around the world.</li>

     Currently, on Debian and Ubuntu, there is a configuration mechanism which

     allows Vidalia to override Tor's ability to start on boot (by sourcing

     <code>/etc/default/tor.vidalia</code> which sets <code>RUN_DAEMON=no</code> at the user's

-    request), but full implementation of <a href="<gitblob>doc/spec/control-spec.txt">ControlPort</a> 

+    request), but full implementation of <a href="<specblob>control-spec.txt">ControlPort</a> 

     communication is still required.

     </p>

@@ -1150,7 +1150,7 @@ meetings around the world.</li>

     href="<gitblob>doc/roadmaps/2008-12-19-roadmap-full.pdf">Tor development

     roadmap</a> for more ideas, or just try out Tor, Vidalia, and Torbutton,

     and find out what you think needs fixing.

-    Some of the <a href="<gittree>doc/spec/proposals">current proposals</a>

+    Some of the <a href="<spectree>proposals">current proposals</a>

     might also be short on developers.

     </li>

@@ -1206,7 +1206,7 @@ meetings around the world.</li>

     href="<page docs/faq>#TransportIPnotTCP">list

     of reasons why we haven't shifted to UDP transport</a>, but it would

     be great to see that list get shorter. We also have a proposed <a

-    href="<gitblob>doc/spec/proposals/100-tor-spec-udp.txt">specification

+    href="<specblob>proposals/100-tor-spec-udp.txt">specification

     for Tor and

     UDP</a> &mdash; please let us know what's wrong with it.</li>

@@ -1230,7 +1230,7 @@ meetings around the world.</li>

     <li>

     Another anti-censorship project is to try to make Tor

     more scanning-resistant.  Right now, an adversary can identify <a

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

+    href="<specblob>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="<svnprojects>design-paper/blocking.html#tth_sEc9.3">act like

@@ -10,6 +10,9 @@

 <define-tag wikifaq whitespace=delete>https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ</define-tag>

 <define-tag blog whitespace=delete>https://blog.torproject.org/blog/</define-tag>

 <define-tag tbbrepo whitespace=delete>https://gitweb.torproject.org/torbrowser.git/blob_plain/HEAD:</define-tag>

+<define-tag specblob whitespace=delete>https://gitweb.torproject.org/torspec.git?a=blob_plain;hb=HEAD;f=</define-tag>

+<define-tag spectree whitespace=delete>https://gitweb.torproject.org/torspec.git?a=tree;hb=HEAD;f=</define-tag>

+

 #  Xinclude "locallinks.wmi"

 #  Xinclude "langlocallinks.$(LANG).wmi"