diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/HACKING | 28 | ||||
| -rw-r--r-- | doc/tor.1.txt | 43 |
2 files changed, 38 insertions, 33 deletions
diff --git a/doc/HACKING b/doc/HACKING index 7ff9c5f3c2..9747f22651 100644 --- a/doc/HACKING +++ b/doc/HACKING @@ -456,7 +456,6 @@ interesting and understandable. 2.7) Run it through fmt to make it pretty. - 3) Compose a short release blurb to highlight the user-facing changes. Insert said release blurb into the ChangeLog stanza. If it's a stable release, add it to the ReleaseNotes file too. If we're adding @@ -472,15 +471,19 @@ or somebody to try building it on Windows. 6) Get at least two of weasel/arma/karsten to put the new version number in their approved versions list. -7) Sign and push the tarball to the website in the dist/ directory. Sign -and push the git tag. - (That's either "git tag -u <keyid> tor-0.2.x.y-status", then - "git push origin tag tor-0.2.x.y-status". To sign the - tarball, "gpg -ba <the_tarball>". Put the files in - /srv/www-master.torproject.org/htdocs/dist/ on vescum.) +7) Sign the tarball, then sign and push the git tag: + gpg -ba <the_tarball> + git tag -u <keyid> tor-0.2.x.y-status + git push origin tag tor-0.2.x.y-status + +8) scp the tarball and its sig to the website in the dist/ directory +(i.e. /srv/www-master.torproject.org/htdocs/dist/ on vescum). Edit +include/versions.wmi to note the new version. From your website checkout, +run ./publish to build and publish the website. -8) Edit include/versions.wmi to note the new version. From your website -checkout, run ./publish to build and publish the website. +Try not to delay too much between scp'ing the tarball and running +./publish -- the website has multiple A records and your scp only sent +it to one of them. 9) Email Erinn and weasel (cc'ing tor-assistants) that a new tarball is up. This step should probably change to mailing more packagers. @@ -492,9 +495,14 @@ box. By convention, we enter the version in the form "Tor: 0.2.2.23-alpha" (or whatever the version is), and we select the date as the date in the ChangeLog. -11) Wait up to a day or two (for a development release), or until most +11) Forward-port the ChangeLog. + +12) Update the topic in #tor to reflect the new version. + +12) Wait up to a day or two (for a development release), or until most packages are up (for a stable release), and mail the release blurb and changelog to tor-talk or tor-announce. (We might be moving to faster announcements, but don't announce until the website is at least updated.) + diff --git a/doc/tor.1.txt b/doc/tor.1.txt index f54b966c27..9ff19e76ab 100644 --- a/doc/tor.1.txt +++ b/doc/tor.1.txt @@ -148,10 +148,11 @@ Other options can be specified either on the command-line (--option **ControlPort** __PORT__|**auto**:: If set, Tor will accept connections on this port and allow those connections to control the Tor process using the Tor Control Protocol - (described in control-spec.txt). Note: unless you also specify one of - **HashedControlPassword** or **CookieAuthentication**, setting this - option will - cause Tor to allow any process on the local host to control it. This + (described in control-spec.txt). Note: unless you also specify one or + more of **HashedControlPassword** or **CookieAuthentication**, + setting this option will cause Tor to allow any process on the local + host to control it. (Setting both authentication methods means either + method is sufficient to authenticate to Tor.) This option is required for many Tor controllers; most use the value of 9051. Set it to "auto" to have Tor pick a port for you. (Default: 0). @@ -173,15 +174,15 @@ Other options can be specified either on the command-line (--option the control socket readable and writable by the default GID. (Default: 0) **HashedControlPassword** __hashed_password__:: - Don't allow any connections on the control port except when the other - process knows the password whose one-way hash is __hashed_password__. You + Allow connections on the control port if they present + the password whose one-way hash is __hashed_password__. You can compute the hash of a password by running "tor --hash-password __password__". You can provide several acceptable passwords by using more than one HashedControlPassword line. **CookieAuthentication** **0**|**1**:: - If this option is set to 1, don't allow any connections on the control port - except when the connecting process knows the contents of a file named + If this option is set to 1, allow connections on the control port + when the connecting process knows the contents of a file named "control_auth_cookie", which Tor will create in its data directory. This authentication method should only be used on systems with good filesystem security. (Default: 0) @@ -509,14 +510,14 @@ The following options are useful only for clients (that is, if patterns of nodes to avoid when building a circuit. (Example: ExcludeNodes SlowServer, $ EFFFFFFFFFFFFFFF, \{cc}, 255.254.0.0/8) + -+ + + By default, this option is treated as a preference that Tor is allowed to override in order to keep working. For example, if you try to connect to a hidden service, but you have excluded all of the hidden service's introduction points, Tor will connect to one of them anyway. If you do not want this behavior, set the StrictNodes option (documented below). + -+ + + Note also that if you are a relay, this (and the other node selection options below) only affects your own circuits that Tor builds for you. Clients can still build circuits through you to any node. Controllers @@ -535,22 +536,22 @@ The following options are useful only for clients (that is, if A list of identity fingerprints, nicknames, country codes and address patterns of nodes to use as exit node---that is, a node that delivers traffic for you outside the Tor network. + -+ + + Note that if you list too few nodes here, or if you exclude too many exit nodes with ExcludeExitNodes, you can degrade functionality. For example, if none of the exits you list allows traffic on port 80 or 443, you won't be able to browse the web. + -+ + + Note also that not every circuit is used to deliver traffic outside of the Tor network. It is normal to see non-exit circuits (such as those used to connect to hidden services, those that do directory fetches, those used for relay reachability self-tests, and so on) that end at a non-exit node. To keep a node from being used entirely, see ExcludeNodes and StrictNodes. + -+ + + The ExcludeNodes option overrides this option: any node listed in both ExitNodes and ExcludeNodes is treated as excluded. + -+ + + The .exit address notation, if enabled via AllowDotExit, overrides this option. @@ -561,7 +562,7 @@ The following options are useful only for clients (that is, if circuits except for direct connections to directory servers. The Bridge option overrides this option; if you have configured bridges and UseBridges is 1, the Bridges are used as your entry nodes. + -+ + + The ExcludeNodes option overrides this option: any node listed in both EntryNodes and ExcludeNodes is treated as excluded. @@ -708,14 +709,10 @@ The following options are useful only for clients (that is, if from the configured bridge authorities when feasible. It will fall back to a direct request if the authority responds with a 404. (Default: 0) -**UseBridges** **0**|**1**|**auto**:: - Make Tor fetch descriptors for each bridge listed in the "Bridge" +**UseBridges** **0**|**1**:: + When set, Tor will fetch descriptors for each bridge listed in the "Bridge" config lines, and use these relays as both entry guards and directory - guards. If the option is 1, bridges must be used and if no bridges are - configured Tor will not make any connections until a bridge is configured; - if it's "auto", Tor will use bridges if any are configured, otherwise it - will connect directly to the Tor network; if it's 0, bridges are not used - at all. (Defaults to auto) + guards. (Default: 0) **UseEntryGuards** **0**|**1**:: If this option is set to 1, we pick a few long-term entry servers, and try @@ -1348,7 +1345,7 @@ The following options are used to configure a hidden service. **HiddenServiceDir** __DIRECTORY__:: Store data files for a hidden service in DIRECTORY. Every hidden service must have a separate directory. You may use this option multiple times to - specify multiple services. + specify multiple services. DIRECTORY must be an existing directory. **HiddenServicePort** __VIRTPORT__ [__TARGET__]:: Configure a virtual port VIRTPORT for a hidden service. You may use this |