mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-10 21:23:58 +01:00
Merge remote-tracking branch 'origin/maint-0.2.4'
This commit is contained in:
Nick Mathewson
commit
ee250be6a6
3
changes/bug8965
Normal file
3
changes/bug8965
Normal file
@ -0,0 +1,3 @@
|
||||
o Removed documentation:
|
||||
- Remove some of the older contents of doc/ as obsolete; move others
|
||||
to torspec.git. Fixes bug 8965.
|
||||
3
doc/TODO
3
doc/TODO
@ -1,3 +0,0 @@
|
||||
|
||||
We no longer track our TODO lists in git. To see open Tor tasks, visit
|
||||
our bugtracker and wiki at trac.torproject.org.
|
||||
@ -1,89 +0,0 @@
|
||||
|
||||
0. Overview.
|
||||
|
||||
This document contains various informal policies for how to operate
|
||||
a directory authority, how to choose new ones, etc.
|
||||
|
||||
1. How to pick a new directory authority.
|
||||
|
||||
Here's our current guidelines for how to pick new directory
|
||||
authorities.
|
||||
|
||||
(These won't ever be formal criteria -- we need to keep this flexible
|
||||
so we can adapt to new situations.)
|
||||
|
||||
o Stability:
|
||||
- Must be a low-downtime Tor server (computer as well as network).
|
||||
- Must have a static IP.
|
||||
- The operator must have been running a stable Tor server for at least
|
||||
3 months.
|
||||
- Must intend for this server to stick around for the next 12 months
|
||||
or more.
|
||||
- Must not hibernate.
|
||||
- Should not be an exit node (as this increases the risk both of
|
||||
downtime and of key compromise).
|
||||
|
||||
o Performance:
|
||||
- Must have sufficient bandwidth: at least 10mbit/s symmetric,
|
||||
though in practice the inbound traffic can be considerably less.
|
||||
|
||||
o Availability:
|
||||
- Must be available to upgrade within a few days in most cases.
|
||||
(While we're still developing Tor, we periodically find bugs that
|
||||
impact the whole network and require authority upgrades.)
|
||||
- Should have a well-known way to contact the administrator
|
||||
via PGP-encrypted message.
|
||||
|
||||
o Integrity:
|
||||
- Must promise not to censor or attack the network and users.
|
||||
- Should be run by somebody that Tor (i.e. Roger) knows.
|
||||
- Should be widely regarded as fair/trustworthy, or at least
|
||||
known, by many people.
|
||||
- If somebody asks you to backdoor or change your server, legally or
|
||||
otherwise, you will fight it to the extent of your abilities. If
|
||||
you fail to fight it, you must shut down the Tor server and notify
|
||||
us that you have.
|
||||
|
||||
o Diversity
|
||||
- We should avoid situations that make it likelier for multiple
|
||||
authority failures to happen at the same time. Therefore...
|
||||
- It's good when authorities are not all in the same country.
|
||||
- It's good when authorities are not all in the same jurisdictions.
|
||||
- It's good when authorities are not all running the same OS.
|
||||
- It's good when authorities are not all using the same ISP.
|
||||
- It's good when authorities are not all running the same
|
||||
version of Tor.
|
||||
- No two authorities should have the same operator.
|
||||
- Maximal diversity, however, is not always practical. Sometimes,
|
||||
for example, there is only one version of Tor that provides a
|
||||
given consensus generation algorithm.
|
||||
- A small group of authorities with the same country/jurisdiction/OS is
|
||||
not a problem, until that group's size approaches quorum (half the
|
||||
authorities).
|
||||
|
||||
2. How to choose the recommended versions
|
||||
|
||||
The policy, in a nutshell, is to not remove versions without a good
|
||||
reason. So this means we should recommend all versions except:
|
||||
|
||||
- Versions that no longer conform to the spec. That is, if they wouldn't
|
||||
actually interact correctly with the current Tor network.
|
||||
- Versions that have known security problems.
|
||||
- Versions that have frequent crash or assert problems.
|
||||
- Versions that harm the performance or stability of the current Tor
|
||||
network or the anonymity of other users. For example, a version
|
||||
that load balances wrong, or a version that hammers the authorities
|
||||
too much.
|
||||
|
||||
|
||||
> some use the slight variant of requiring a *good* reason.
|
||||
> excellent reasons include "there's a security flaw"
|
||||
> good reasons include "that crashes every time you start it. you would think
|
||||
+tor is dumb if you tried to use that version and think of it as tor."
|
||||
> good reasons include "those old clients do their load balancing wrong, and
|
||||
+they're screwing up the whole network"
|
||||
> reasons include "the old one is really slow, clients should prefer the new
|
||||
+one"
|
||||
> i try to draw the line at 'good reasons and above'
|
||||
|
||||
|
||||
@ -1,181 +0,0 @@
|
||||
Design For A Tor DNS-based Exit List
|
||||
|
||||
Status:
|
||||
|
||||
This is a suggested design for a DNS Exit List (DNSEL) for Tor exit nodes.
|
||||
See http://exitlist.torproject.org/ for an implementation.
|
||||
|
||||
Why?
|
||||
|
||||
It's useful for third parties to be able to tell when a given connection
|
||||
is coming from a Tor exit node. Potential applications range from
|
||||
"anonymous user" cloaks on IRC networks like oftc, to networks like
|
||||
Freenode that apply special authentication rules to users from these
|
||||
IPs, to systems like Wikipedia that may want to make a priority of
|
||||
_unblocking_ shared IPs more liberally than non-shared IPs, since shared
|
||||
IPs presumably have non-abusive users as well as abusive ones.
|
||||
|
||||
Since Tor provides exit policies, not every Tor server will connect to
|
||||
every address:port combination on the Internet. Unless you're trying to
|
||||
penalize hosts for supporting anonymity, it makes more sense to answer
|
||||
the fine-grained question "which Tor servers will connect to _me_?" than
|
||||
the coarse-grained question "which Tor servers exist?" The fine-grained
|
||||
approach also helps Tor server ops who share an IP with their Tor
|
||||
server: if they want to access a site that blocks Tor users, they
|
||||
can exclude that site from their exit policy, and the site can learn
|
||||
that they won't send it anonymous connections.
|
||||
|
||||
Tor already ships with a tool (the "contrib/exitlist" script) to
|
||||
identify which Tor nodes might open anonymous connections to any given
|
||||
exit address. But this is a bit tricky to set up, so only sites like
|
||||
Freenode and OFTC that are dedicated to privacy use it.
|
||||
Conversely, providers of some DNSEL implementations are providing
|
||||
coarse-grained lists of Tor hosts -- sometimes even listing servers that
|
||||
permit no exit connections at all. This is rather a problem, since
|
||||
support for DNSEL is pretty ubiquitous.
|
||||
|
||||
|
||||
How?
|
||||
|
||||
Keep a running Tor instance, and parse the cached-routers and
|
||||
cached-routers.new files as new routers arrive. To tell whether a given
|
||||
server allows connections to a certain address:port combo, look at the
|
||||
definitions in dir-spec.txt or follow the logic of the current exitlist
|
||||
script. If bug 405 is still open when you work on this
|
||||
(https://bugs.torproject.org/flyspray/index.php?do=details&id=405), you'll
|
||||
probably want to extend it to look at only the newest descriptor for
|
||||
each server, so you don't use obsolete exit policy data.
|
||||
|
||||
FetchUselessDescriptors would probably be a good torrc option to enable.
|
||||
|
||||
If you're also running a directory cache, you get extra-fresh
|
||||
information.
|
||||
|
||||
|
||||
The DNS interface
|
||||
|
||||
Standard DNSEL, if I understand right, looks like this: There's some
|
||||
authoritative name server for foo.example.com. You want to know if
|
||||
1.2.3.4 is in the list, so you query for an A record for
|
||||
4.3.2.1.foo.example.com. If the record exists and has the value
|
||||
127.0.0.2[DNSBL-EMAIL], 1.2.3.4 is in the list. If you get an NXDOMAIN
|
||||
error, 1.2.3.4 is not in the list. If you ask for a domain name outside
|
||||
of the foo.example.com zone, you get a Server Failure error[RFC 1035].
|
||||
|
||||
Assume that the DNSEL answers queries authoritatively for some zone,
|
||||
torhosts.example.com. Below are some queries that could be supported,
|
||||
though some of them are possibly a bad idea.
|
||||
|
||||
|
||||
Query type 1: "General IP:Port"
|
||||
|
||||
Format:
|
||||
{IP1}.{port}.{IP2}.ip-port.torhosts.example.com
|
||||
|
||||
Rule:
|
||||
Iff {IP1} is a Tor server that permits connections to {port} on
|
||||
{IP2}, then there should be an A record with the value 127.0.0.2.
|
||||
|
||||
Example:
|
||||
"1.0.0.10.80.4.3.2.1.ip-port.torhosts.example.com" should have the
|
||||
value 127.0.0.2 if and only if there is a Tor server at 10.0.0.1
|
||||
that allows connections to port 80 on 1.2.3.4.
|
||||
|
||||
Example use:
|
||||
I'm running an IRC server at w.x.y.z:9999, and I want to tell
|
||||
whether an incoming connection is from a Tor server. I set
|
||||
up my IRC server to give a special mask to any user coming from
|
||||
an IP listed in 9999.z.y.x.w.ip-port.torhosts.example.com.
|
||||
|
||||
Later, when I get a connection from a.b.c.d, my ircd looks up
|
||||
"d.c.b.a.9999.z.y.x.w.ip-port.torhosts.example.com" to see
|
||||
if it's a Tor server that allows connections to my ircd.
|
||||
|
||||
|
||||
Query type 2: "IP-port group"
|
||||
|
||||
Format:
|
||||
{IP}.{listname}.list.torhosts.example.com
|
||||
|
||||
Rule:
|
||||
Iff this Tor server is configured with an IP:Port list named
|
||||
{listname}, and {IP} is a Tor server that permits connections to
|
||||
any member of {listname}, then there exists an A record.
|
||||
|
||||
Example:
|
||||
Suppose torhosts.example.com has a list of IP:Port called "foo".
|
||||
There is an A record for 4.3.2.1.foo.list.torhosts.example.com
|
||||
if and only if 1.2.3.4 is a Tor server that permits connections
|
||||
to one of the addresses in list "foo".
|
||||
|
||||
Example use:
|
||||
Suppose torhosts.example.com has a list of hosts in "examplenet",
|
||||
a popular IRC network. Rather than having them each set up to
|
||||
query the appropriate "ip-port" list, they could instead all be
|
||||
set to query a central examplenet.list.torhosts.example.com.
|
||||
|
||||
Problems:
|
||||
We'd be better off if each individual server queried about hosts
|
||||
that allowed connections to itself. That way, if I wanted to
|
||||
allow anonymous connections to foonet, but I wanted to be able to
|
||||
connect to foonet from my own IP without being marked, I could add
|
||||
just a few foonet addresses to my exit policy.
|
||||
|
||||
|
||||
Query type 3: "My IP, with port"
|
||||
|
||||
Format:
|
||||
{IP}.{port}.me.torhosts.example.com
|
||||
|
||||
Rule:
|
||||
An A record exists iff there is a tor server at {IP} that permits
|
||||
connections to {port} on the host that requested the lookup.
|
||||
|
||||
Example:
|
||||
"4.3.2.1.80.me.torhosts.example.com" should have an A record if
|
||||
and only if there is a Tor server at 1.2.3.4 that allows
|
||||
connections to port 80 of the querying host.
|
||||
|
||||
Example use:
|
||||
Somebody wants to set up a quick-and-dirty Tor detector for a
|
||||
single webserver: just point them at 80.me.torhosts.example.com.
|
||||
|
||||
Problem:
|
||||
This would be easiest to use, but DNS gets in the way. If you
|
||||
create DNS records that give different results depending on who is
|
||||
asking, you mess up caching. There could be a fix here, but might
|
||||
not.
|
||||
|
||||
|
||||
RECOMMENDATION: Just build ip-port for now, and see what demand is
|
||||
like. There's no point in building mechanisms nobody wants.
|
||||
|
||||
Web interface:
|
||||
|
||||
Should provide the same data as the dns interface.
|
||||
|
||||
Other issues:
|
||||
|
||||
After a Tor server op turns off their server, it stops publishing server
|
||||
descriptors. We should consider that server's IP address to still
|
||||
represent a Tor node until 48 hours after its last descriptor was
|
||||
published.
|
||||
|
||||
30-60 minutes is not an unreasonable TTL.
|
||||
|
||||
There could be some demand for address masks and port lists. Address
|
||||
masks wider than /8 make me nervous here, as do port ranges.
|
||||
|
||||
We need an answer for what to do about hosts which exit from different
|
||||
IPs than their advertised IP. One approach would be for the DNSEL
|
||||
to launch periodic requests to itself through all exit servers whose
|
||||
policies allow it -- and then see where the requests actually come from.
|
||||
|
||||
References:
|
||||
|
||||
[DNSBL-EMAIL] Levine, J., "DNS Based Blacklists and Whitelists for
|
||||
E-Mail", http://tools.ietf.org/html/draft-irtf-asrg-dnsbl-02, November
|
||||
2005.
|
||||
|
||||
[RFC 1035] Mockapetris, P., "Domain Names - Implementation and
|
||||
Specification", RFC 1035, November 1987.
|
||||
@ -36,8 +36,6 @@ endif
|
||||
|
||||
EXTRA_DIST+= doc/HACKING doc/asciidoc-helper.sh \
|
||||
$(html_in) $(man_in) $(txt_in) \
|
||||
doc/tor-rpm-creation.txt \
|
||||
doc/tor-win32-mingw-creation.txt doc/spec/README \
|
||||
doc/state-contents.txt
|
||||
|
||||
docdir = @docdir@
|
||||
|
||||
@ -1,11 +0,0 @@
|
||||
The Tor specifications and proposals have moved to a new repository.
|
||||
|
||||
To browse the specifications, go to
|
||||
https://gitweb.torproject.org/torspec.git/tree
|
||||
|
||||
To check out the specification repository, run
|
||||
git clone git://git.torproject.org/torspec.git
|
||||
|
||||
For other information on the repository, see
|
||||
https://gitweb.torproject.org/torspec.git
|
||||
|
||||
@ -1,119 +0,0 @@
|
||||
##
|
||||
## Instructions for building Tor with MinGW (http://www.mingw.org/)
|
||||
##
|
||||
|
||||
Stage One: Download and Install MinGW.
|
||||
---------------------------------------
|
||||
|
||||
Download mingw:
|
||||
http://prdownloads.sf.net/mingw/MinGW-5.1.6.exe?download
|
||||
|
||||
Download msys:
|
||||
http://prdownloads.sf.net/ming/MSYS-1.0.11.exe?download
|
||||
|
||||
Download msysDTK:
|
||||
http://sourceforge.net/projects/mingw/files/MSYS%20Supplementary%20Tools/msysDTK-1.0.1/msysDTK-1.0.1.exe/download
|
||||
|
||||
Install MinGW, msysDTK, and MSYS in that order.
|
||||
|
||||
Make sure your PATH includes C:\MinGW\bin. You can verify this by right
|
||||
clicking on "My Computer", choose "Properties", choose "Advanced",
|
||||
choose "Environment Variables", select PATH.
|
||||
|
||||
Start MSYS(rxvt).
|
||||
|
||||
Create a directory called "tor-mingw".
|
||||
|
||||
Stage Two: Download, extract, compile openssl
|
||||
----------------------------------------------
|
||||
|
||||
Download openssl:
|
||||
http://www.openssl.org/source/openssl-0.9.8l.tar.gz
|
||||
|
||||
Extract openssl:
|
||||
Copy the openssl tarball into the "tor-mingw" directory.
|
||||
Type "cd tor-mingw/"
|
||||
Type "tar zxf openssl-0.9.8l.tar.gz"
|
||||
(Note: There are many symlink errors because Windows doesn't support
|
||||
symlinks. You can ignore these errors.)
|
||||
|
||||
Make openssl libraries:
|
||||
Type "cd tor-mingw/openssl-0.9.8l/"
|
||||
Type "./Configure -no-idea -no-rc5 -no-mdc2 mingw"
|
||||
Edit Makefile and remove the "test:" and "tests:" sections.
|
||||
Type "rm -rf ./test"
|
||||
Type "cd crypto/"
|
||||
Type "find ./ -name "*.h" -exec cp {} ../include/openssl/ \;"
|
||||
Type "cd ../ssl/"
|
||||
Type "find ./ -name "*.h" -exec cp {} ../include/openssl/ \;"
|
||||
Type "cd .."
|
||||
Type "cp *.h include/openssl/"
|
||||
Type "find ./fips -type f -name "*.h" -exec cp {} include/openssl/ \;"
|
||||
# The next steps can take up to 30 minutes to complete.
|
||||
Type "make"
|
||||
Type "make install"
|
||||
|
||||
|
||||
Stage Three: Download, extract, compile zlib
|
||||
---------------------------------------------
|
||||
|
||||
Download zlib source:
|
||||
http://www.zlib.net/zlib-1.2.3.tar.gz
|
||||
|
||||
Extract zlib:
|
||||
Copy the zlib tarball into the "tor-mingw" directory
|
||||
Type "cd tor-mingw/"
|
||||
Type "tar zxf zlib-1.2.3.tar.gz"
|
||||
|
||||
CHOICE:
|
||||
|
||||
Make zlib.a:
|
||||
Type "cd tor-mingw/zlib-1.2.3/"
|
||||
Type "./configure"
|
||||
Type "make"
|
||||
Type "make install"
|
||||
|
||||
Done.
|
||||
|
||||
|
||||
Stage Four: Download, extract, and compile libevent
|
||||
------------------------------------------------------
|
||||
|
||||
Download the latest libevent release:
|
||||
http://www.monkey.org/~provos/libevent/
|
||||
|
||||
Copy the libevent tarball into the "tor-mingw" directory.
|
||||
Type "cd tor-mingw"
|
||||
|
||||
Extract libevent.
|
||||
|
||||
Type "./configure --enable-static --disable-shared"
|
||||
Type "make"
|
||||
Type "make install"
|
||||
|
||||
Stage Five: Build Tor
|
||||
----------------------
|
||||
|
||||
Download the current Tor alpha release source code from https://torproject.org/download.html.
|
||||
Copy the Tor tarball into the "tor-mingw" directory.
|
||||
Extract Tor:
|
||||
Type "tar zxf latest-tor-alpha.tar.gz"
|
||||
|
||||
cd tor-<version>
|
||||
Type "./configure"
|
||||
Type "make"
|
||||
|
||||
You now have a tor.exe in src/or/. This is Tor.
|
||||
You now have a tor-resolve.exe in src/tools/.
|
||||
|
||||
Stage Six: Build the installer
|
||||
-------------------------------
|
||||
|
||||
Install the latest NSIS:
|
||||
http://nsis.sourceforge.net/Download
|
||||
|
||||
Run the package script in contrib:
|
||||
From the Tor build directory above, run:
|
||||
"./contrib/package_nsis-mingw.sh"
|
||||
|
||||
The resulting Tor installer executable is in ./win_tmp/.
|
||||
@ -1,182 +0,0 @@
|
||||
## Instructions for helping translate text for Vidalia, TorButton
|
||||
## and TorCheck
|
||||
## ( More translation information for Tor related apps will accumulate here )
|
||||
|
||||
Our translations are handled in one of two places. The Tor Translation Portal
|
||||
handles all of the translations for Vidalia, Torbutton and TorCheck. The Tor
|
||||
website itself is currently handled by hand translations using subversion.
|
||||
|
||||
-------------------------------------------------------------------------
|
||||
|
||||
For the Tor website, you'll need a Tor SVN account.
|
||||
If you do not have one and you need one, please run this command with your
|
||||
desired username in place of 'USERNAME':
|
||||
htdigest -c passwd.tmp "Tor subversion repository" USERNAME
|
||||
and send us the contents of passwd.tmp.
|
||||
|
||||
-------------------------------------------------------------------------
|
||||
|
||||
For the Portal-based projects, all three check in their respective .po
|
||||
files into the following subversion urls:
|
||||
|
||||
https://tor-svn.freehaven.net/svn/translation/trunk/projects/torbutton
|
||||
https://tor-svn.freehaven.net/svn/translation/trunk/projects/torcheck
|
||||
https://svn.vidalia-project.net/svn/vidalia/trunk/src/vidalia/i18n/
|
||||
|
||||
The current pootle configuration is checked into subversion as well:
|
||||
|
||||
https://tor-svn.freehaven.net/svn/translation/trunk/pootle
|
||||
|
||||
---------------------------- TorCheck -------------------------------
|
||||
|
||||
TorCheck uses our translation portal to accept translations. Users use
|
||||
the portal to check in their changes. To make use of the translations
|
||||
that users have committed to the translations/ subversion module, you'll
|
||||
need to ensure that you have a current checked out copy of TorCheck:
|
||||
|
||||
cd check/trunk/i18n/
|
||||
check/trunk/i18n$ svn up
|
||||
|
||||
You should see something like the following:
|
||||
|
||||
Fetching external item into 'pootle'
|
||||
External at revision 15300.
|
||||
|
||||
At revision 15300.
|
||||
|
||||
Now if you had changes, you'd simply want to move the newly updated .po files
|
||||
into the current stable directory. Moving the .po files from
|
||||
'check/trunk/i18n/pootle/' into 'check/trunk/i18n' properly naming the files
|
||||
for their respective locale.
|
||||
|
||||
Here's an example of how to move all of the current pootle translations into
|
||||
the svn trunk area of TorCheck:
|
||||
|
||||
cd check/trunk/i18n/
|
||||
for locale in `ls -1 pootle/|grep -v template`;
|
||||
do
|
||||
mv -v pootle/$locale/TorCheck_$locale.po TorCheck_$locale.po;
|
||||
done
|
||||
|
||||
Now check the differences (ensure the output looks reasonable):
|
||||
|
||||
svn diff
|
||||
|
||||
Ensure that msgfmt has no errors:
|
||||
|
||||
msgfmt -C *.po
|
||||
|
||||
And finally check in the changes:
|
||||
|
||||
svn commit
|
||||
|
||||
---------------------------- Torbutton -------------------------------
|
||||
|
||||
Torbutton uses our translation portal to accept translations. Users use
|
||||
the portal to check in their changes.
|
||||
|
||||
To make use of the translations that users have committed to the translations/
|
||||
subversion module, you'll need to ensure that you have a current checked out
|
||||
copy of them in your torbutton git checkout:
|
||||
|
||||
cd torbutton.git/trans_tools
|
||||
torbutton.git/trans_tools$ svn co https://tor-svn.freehaven.net/svn/translation/trunk/projects/torbutton pootle
|
||||
|
||||
You should see something like the following:
|
||||
|
||||
Checked out revision 21092.
|
||||
|
||||
If you made changes to strings in Torbutton, you need to rebuild the
|
||||
templates in torbutton.git/trans_tools/pootle/templates. This is done with
|
||||
the following command from within the torbutton.git checkout directory:
|
||||
|
||||
moz2po -P -i src/chrome/locale/en/ -o trans_tools/pootle/templates/
|
||||
|
||||
You now have two options:
|
||||
|
||||
Option 1 (The [shitty] Pootle Web UI Way):
|
||||
|
||||
View then commit the changes to the template with:
|
||||
|
||||
cd trans_tools/pootle
|
||||
svn diff templates
|
||||
svn commit templates
|
||||
|
||||
Then poke Jake to 'svn up' on the Pootle side. If you do this enough
|
||||
times, he may give you a button to click to update templates in Pootle,
|
||||
or maybe even an account on the Pootle server. Persistence is a virtue.
|
||||
|
||||
You then need to go to the Pootle website and click the checkbox next to
|
||||
every language on:
|
||||
https://translation.torproject.org/projects/torbutton/admin.html
|
||||
and then click "Update Languages" at the bottom.
|
||||
|
||||
You then need to go to each language and go to "Editing Options" and click
|
||||
"Commit" for each one.
|
||||
|
||||
You then need to 'svn up' locally, and follow the procedure above for
|
||||
rebuilding your .dtd and .properties files.
|
||||
|
||||
Yes, this sucks. :/
|
||||
|
||||
Option 2 (Use your own msgmerge: YMMV, may change .po flags and formatting):
|
||||
|
||||
Run msgmerge yourself for each language:
|
||||
|
||||
cd trans_tools
|
||||
for i in `ls -1 pootle`
|
||||
do
|
||||
msgmerge -U ./pootle/$i/torbutton.dtd.po ./pootle/templates/torbutton.dtd.pot
|
||||
msgmerge -U ./pootle/$i/torbutton.properties.po ./pootle/templates/torbutton.properties.pot
|
||||
done
|
||||
svn diff pootle
|
||||
svn commit pootle
|
||||
|
||||
Then poke Jake to 'svn up' on the Pootle side. If you do this enough times,
|
||||
he may give you a button on Pootle, or maybe even an account on the Pootle
|
||||
server. Persistence is a virtue.
|
||||
|
||||
You may notice that some .po file flags and string formatting have changed
|
||||
with this method, depending on your gettext version. It is unclear if this
|
||||
is a problem. Please update this doc if you hit a landmine and everything
|
||||
breaks :)
|
||||
|
||||
After this process is done, you then need to regenerate the mozilla
|
||||
.dtd and .properties files as specified above.
|
||||
|
||||
|
||||
Regardless of whether or not you had changes in the torbutton strings, if there
|
||||
were updated strings in pootle that you checked out from svn you now need to
|
||||
convert from .po and move the newly updated mozilla files into the current
|
||||
stable locale directory. First convert them with the 'mkmoz.sh' script and
|
||||
then move the proper mozilla files from 'torbutton.git/trans_tools/moz/' into
|
||||
'torbutton.git/src/chrome/locale/' directory while properly naming the files
|
||||
for their respective locale.
|
||||
|
||||
Here's an example of how to move all of the current pootle translations into
|
||||
the svn trunk area of Torbutton:
|
||||
|
||||
cd trans_tools
|
||||
./mkmoz.sh
|
||||
for locale in `ls -1 moz/`;
|
||||
do
|
||||
mv -v moz/$locale/*.{dtd,properties} ../src/chrome/locale/$locale/
|
||||
done
|
||||
|
||||
Now check the differences to your git branch to ensure the output looks
|
||||
reasonable:
|
||||
|
||||
cd ..
|
||||
git diff
|
||||
|
||||
And finally check in the changes:
|
||||
|
||||
cd src/chrome/locale
|
||||
git commit .
|
||||
|
||||
---------------------------- Vidalia -------------------------------
|
||||
|
||||
Vidalia uses our translation portal to accept translations. Users use the
|
||||
portal to check in their changes. No conversion or moving is required other
|
||||
than normal pootle usage.
|
||||
|
||||
@ -1,84 +0,0 @@
|
||||
|
||||
How to add a v3 directory authority.
|
||||
|
||||
What we'll be doing:
|
||||
|
||||
We'll be configuring your Tor server as a v3 directory authority,
|
||||
generating a v3 identity key plus certificates, and adding your v3
|
||||
identity fingerprint to the list of default directory authorities.
|
||||
|
||||
The steps:
|
||||
|
||||
0) Make sure you're running ntp, and that your time is correct.
|
||||
|
||||
Make sure you have Tor version at least r12724. In the short term,
|
||||
running a working authority may mean running the latest version of
|
||||
Tor from SVN trunk. Later on, we hope that it will become easier
|
||||
and you can just run a recent development release (and later still,
|
||||
a recent stable release).
|
||||
|
||||
1) First, you'll need a certificate. Run ./src/tools/tor-gencert to
|
||||
generate one.
|
||||
|
||||
Run tor-gencert in a separate, very secure directory. Maybe even on
|
||||
a more secure computer. The first time you run it, you will need to
|
||||
run it with the --create-identity-key option to make a v3 authority
|
||||
identity key. Subsequent times, you can just run it as-is.
|
||||
|
||||
tor-gencert will make 3 files:
|
||||
|
||||
authority_identity_key -- THIS IS VERY SECRET AND VERY SENSITIVE.
|
||||
DO NOT LEAK IT. DO NOT LOSE IT.
|
||||
|
||||
authority_signing_key -- A key for signing votes and v3 conensuses.
|
||||
|
||||
authority_certificate -- A document authenticating your signing key
|
||||
with your identity-key.
|
||||
|
||||
You will need to rotate your signing key periodically. The current
|
||||
default lifetime is 1 year. We'll probably take this down to a month or
|
||||
two some time soon. To rotate your key, run tor-gencert as before,
|
||||
but without the --create-identity-key option.
|
||||
|
||||
2) Copy authority_signing_key and authority_certificate to your Tor keys
|
||||
directory.
|
||||
|
||||
For example if your data directory is /var/lib/tor/, you should run
|
||||
cp authority_signing_key authority_certificate /var/lib/tor/keys/
|
||||
|
||||
You will need to repeat this every time you rotate your certificate.
|
||||
|
||||
3) Tell your Tor to be a v3 authority by adding these lines to your torrc:
|
||||
|
||||
AuthoritativeDirectory 1
|
||||
V3AuthoritativeDirectory 1
|
||||
|
||||
4) Now your authority is generating a networkstatus opinion (called a
|
||||
"vote") every period, but none of the other authorities care yet. The
|
||||
next step is to get a Tor developer (likely Roger or Nick) to add
|
||||
your v3 identity fingerprint to the default list of dirservers.
|
||||
|
||||
First, you need to learn your authority's v3 identity fingerprint.
|
||||
It should be in your authority_certificate file in a line like:
|
||||
|
||||
fingerprint 3041632465FA8847A98B2C5742108C72325532D9
|
||||
|
||||
One of the Tor developers then needs to add this fingerprint to
|
||||
the add_default_trusted_dirservers() function in config.c, using
|
||||
the syntax "v3ident=<fingerprint>". For example, if moria1's new v3
|
||||
identity fingerprint is FOO, the moria1 dirserver line should now be:
|
||||
|
||||
DirServer moria1 v1 orport=9001 v3ident=FOO 128.31.0.34:9031 FFCB 46DB 1339 DA84 674C 70D7 CB58 6434 C437 0441
|
||||
|
||||
The v3ident item must appear after the nickname and before the IP.
|
||||
|
||||
5) Once your fingerprint has been added to config.c, we will try to
|
||||
get a majority of v3 authorities to upgrade, so they know about you
|
||||
too. At that point your vote will automatically be included in the
|
||||
networkstatus consensus, and you'll be a fully-functioning contributing
|
||||
v3 authority.
|
||||
|
||||
Note also that a majority of the configured v3 authorities need to
|
||||
agree in order to generate a consensus: so this is also the point
|
||||
where extended downtime on your server means missing votes.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user