Browse code

Fix links that broke due to splitting the spec in its own repo

Sebastian Hahn authored on21/02/2011 23:10:53
Showing7 changed files
... ...
@@ -24,7 +24,7 @@ a fuzzer for Tor; mentored by Roger.</dd>
24 24
 Improving Tor Path Selection (<a
25 25
 href="https://svn.torproject.org/cgi-bin/viewvc.cgi/torflow/branches/gsoc2008/">svn</a>)
26 26
 and <a
27
-href="<gitblob>doc/spec/proposals/151-path-selection-improvements.txt">proposal
27
+href="<specblob>proposals/151-path-selection-improvements.txt">proposal
28 28
 151</a> as part of Google Summer of Code 2008.</dd>
29 29
 <dt>Bram Cohen</dt><dd>Helped design our congestion control mechanisms,
30 30
 in Tor's early days.</dd>
... ...
@@ -105,7 +105,7 @@
105 105
           press, and general support.</dd>
106 106
           <dt>Dr. Karsten Loesing, Researcher and Developer</dt>
107 107
           <dd>Worked during the 2007 Google Summer of Code on <a
108
-          href="<gitblob>doc/spec/proposals/114-distributed-storage.txt">distributing
108
+          href="<specblob>proposals/114-distributed-storage.txt">distributing
109 109
           and securing the publishing and fetching of hidden
110 110
           service descriptors</a>. Currently the primary
111 111
           researcher for our National Science Foundation grant
... ...
@@ -192,7 +192,7 @@
192 192
     <p>
193 193
     If you would like to learn more about our bridge
194 194
     design from a technical standpoint, please read the <a
195
-    href="<gitblob>doc/spec/bridges-spec.txt">Tor bridges
195
+    href="<specblob>bridges-spec.txt">Tor bridges
196 196
     specification</a>. If you're interested in running an unpublished bridge
197 197
     or other non-standard uses, please do read the specification.
198 198
     </p>
... ...
@@ -137,9 +137,9 @@
137 137
     
138 138
     <li>
139 139
     Learn about the <a
140
-    href="<gitblob>doc/spec/proposals/001-process.txt">Tor
140
+    href="<specblob>proposals/001-process.txt">Tor
141 141
     proposal process for changing our design</a>, and look over the <a
142
-    href="<gittree>doc/spec/proposals">existing proposals</a>.
142
+    href="<spectree>proposals">existing proposals</a>.
143 143
     </li>
144 144
     
145 145
     <li>
... ...
@@ -210,25 +210,25 @@
210 210
     <li>The <b>specifications</b> aim to give
211 211
     developers enough information to build a compatible version of Tor:
212 212
     <ul>
213
-    <li><a href="<gitblob>doc/spec/tor-spec.txt">Main Tor specification</a></li>
214
-    <li><a href="<gitblob>doc/spec/dir-spec.txt">Tor
213
+    <li><a href="<specblob>tor-spec.txt">Main Tor specification</a></li>
214
+    <li><a href="<specblob>dir-spec.txt">Tor
215 215
     version 3 directory server specification</a> (and older <a
216
-    href="<gitblob>doc/spec/dir-spec-v1.txt">version 1</a> and <a
217
-    href="<gitblob>doc/spec/dir-spec-v2.txt">version 2</a> directory
216
+    href="<specblob>dir-spec-v1.txt">version 1</a> and <a
217
+    href="<specblob>dir-spec-v2.txt">version 2</a> directory
218 218
     specifications)</li>
219
-    <li><a href="<gitblob>doc/spec/control-spec.txt">Tor control protocol
219
+    <li><a href="<specblob>control-spec.txt">Tor control protocol
220 220
     specification</a></li>
221
-    <li><a href="<gitblob>doc/spec/rend-spec.txt">Tor rendezvous
221
+    <li><a href="<specblob>rend-spec.txt">Tor rendezvous
222 222
     specification</a></li>
223
-    <li><a href="<gitblob>doc/spec/path-spec.txt">Tor path selection
223
+    <li><a href="<specblob>path-spec.txt">Tor path selection
224 224
     specification</a></li>
225
-    <li><a href="<gitblob>doc/spec/address-spec.txt">Special hostnames in
225
+    <li><a href="<specblob>address-spec.txt">Special hostnames in
226 226
     Tor</a></li>
227
-    <li><a href="<gitblob>doc/spec/socks-extensions.txt">Tor's SOCKS support
227
+    <li><a href="<specblob>socks-extensions.txt">Tor's SOCKS support
228 228
     and extensions</a></li>
229
-    <li><a href="<gitblob>doc/spec/version-spec.txt">How Tor version numbers
229
+    <li><a href="<specblob>version-spec.txt">How Tor version numbers
230 230
     work</a></li>
231
-    <li><a href="<gittree>doc/spec/proposals">In-progress drafts of
231
+    <li><a href="<spectree>proposals">In-progress drafts of
232 232
     new specifications and proposed changes</a></li>
233 233
     </ul></li>
234 234
     
... ...
@@ -1461,7 +1461,7 @@ the same geographic location.
1461 1461
     have the right keys for them? Each relay has a long-term public signing
1462 1462
     key called the "identity key". Each directory authority additionally has a
1463 1463
     "directory signing key". The directory authorities <a
1464
-    href="<gitblob>doc/spec/dir-spec.txt">provide a signed list</a>
1464
+    href="<specblob>dir-spec.txt">provide a signed list</a>
1465 1465
     of all the known relays, and in that list are a set of certificates from
1466 1466
     each relay (self-signed by their identity key) specifying their keys,
1467 1467
     locations, exit policies, and so on. So unless the adversary can control
... ...
@@ -665,7 +665,7 @@ meetings around the world.</li>
665 665
     <p>If you want to get more into the guts of Tor itself (C), a more minor problem
666 666
     we should address is that current Tors can only listen on a single
667 667
     address/port combination at a time. There's
668
-    <a href="<gitblob>doc/spec/proposals/118-multiple-orports.txt">a
668
+    <a href="<specblob>proposals/118-multiple-orports.txt">a
669 669
     proposal to address this limitation</a> and allow clients to connect
670 670
     to any given Tor on multiple addresses and ports, but it needs more
671 671
     work.</p>
... ...
@@ -1096,7 +1096,7 @@ meetings around the world.</li>
1096 1096
     Currently, on Debian and Ubuntu, there is a configuration mechanism which
1097 1097
     allows Vidalia to override Tor's ability to start on boot (by sourcing
1098 1098
     <code>/etc/default/tor.vidalia</code> which sets <code>RUN_DAEMON=no</code> at the user's
1099
-    request), but full implementation of <a href="<gitblob>doc/spec/control-spec.txt">ControlPort</a> 
1099
+    request), but full implementation of <a href="<specblob>control-spec.txt">ControlPort</a> 
1100 1100
     communication is still required.
1101 1101
     </p>
1102 1102
     
... ...
@@ -1150,7 +1150,7 @@ meetings around the world.</li>
1150 1150
     href="<gitblob>doc/roadmaps/2008-12-19-roadmap-full.pdf">Tor development
1151 1151
     roadmap</a> for more ideas, or just try out Tor, Vidalia, and Torbutton,
1152 1152
     and find out what you think needs fixing.
1153
-    Some of the <a href="<gittree>doc/spec/proposals">current proposals</a>
1153
+    Some of the <a href="<spectree>proposals">current proposals</a>
1154 1154
     might also be short on developers.
1155 1155
     </li>
1156 1156
     
... ...
@@ -1206,7 +1206,7 @@ meetings around the world.</li>
1206 1206
     href="<page docs/faq>#TransportIPnotTCP">list
1207 1207
     of reasons why we haven't shifted to UDP transport</a>, but it would
1208 1208
     be great to see that list get shorter. We also have a proposed <a
1209
-    href="<gitblob>doc/spec/proposals/100-tor-spec-udp.txt">specification
1209
+    href="<specblob>proposals/100-tor-spec-udp.txt">specification
1210 1210
     for Tor and
1211 1211
     UDP</a> &mdash; please let us know what's wrong with it.</li>
1212 1212
     
... ...
@@ -1230,7 +1230,7 @@ meetings around the world.</li>
1230 1230
     <li>
1231 1231
     Another anti-censorship project is to try to make Tor
1232 1232
     more scanning-resistant.  Right now, an adversary can identify <a
1233
-    href="<gitblob>doc/spec/proposals/125-bridges.txt">Tor bridges</a>
1233
+    href="<specblob>proposals/125-bridges.txt">Tor bridges</a>
1234 1234
     just by trying to connect to them, following the Tor protocol,
1235 1235
     and seeing if they respond.  To solve this, bridges could <a
1236 1236
     href="<svnprojects>design-paper/blocking.html#tth_sEc9.3">act like
... ...
@@ -10,6 +10,9 @@
10 10
 <define-tag wikifaq whitespace=delete>https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ</define-tag>
11 11
 <define-tag blog whitespace=delete>https://blog.torproject.org/blog/</define-tag>
12 12
 <define-tag tbbrepo whitespace=delete>https://gitweb.torproject.org/torbrowser.git/blob_plain/HEAD:</define-tag>
13
+<define-tag specblob whitespace=delete>https://gitweb.torproject.org/torspec.git?a=blob_plain;hb=HEAD;f=</define-tag>
14
+<define-tag spectree whitespace=delete>https://gitweb.torproject.org/torspec.git?a=tree;hb=HEAD;f=</define-tag>
15
+
13 16
 
14 17
 #  Xinclude "locallinks.wmi"
15 18
 #  Xinclude "langlocallinks.$(LANG).wmi"