Merge branch 'maint-0.2.4' into release-0.2.4
This commit is contained in:
Roger Dingledine
commit
d78bb2df0e
|
|
@ -0,0 +1,5 @@
|
|||
o Normal bugfixes:
|
||||
- When launching a resolve request on behalf of an AF_UNIX control
|
||||
socket, omit the address field of the new entry connection, used in
|
||||
subsequent controller events, rather than letting tor_dup_addr() set
|
||||
it to "<unknown address type>". Fixes bug 8639.
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
o Major bugfixes (windows):
|
||||
- Prevent failures on Windows Vista and later when rebuilding the
|
||||
microdescriptor cache. Diagnosed by Robert Ransom. Fixes bug 8822;
|
||||
bugfix on 0.2.4.12-alpha.
|
||||
|
||||
|
|
@ -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.
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
o Minor bugfixes:
|
||||
- If for some reason we fail to write a microdescriptor while
|
||||
rebuilding the cache, do not let the annotations from that
|
||||
microdescriptor linger in the cache file, and do not let the
|
||||
microdescriptor stay recorded as present in its old location.
|
||||
Fixes bug 9047; bugfix on 0.2.2.6-alpha.
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
o Normal bugfixes:
|
||||
- Close any circuit that has more cells queued than the spec permits.
|
||||
Fixes bug #9063; bugfix on 0.2.4.12.
|
||||
20
doc/HACKING
20
doc/HACKING
|
|
@ -12,7 +12,7 @@ https://gitweb.torproject.org/torspec.git/blob_plain/HEAD:/proposals/001-process
|
|||
|
||||
For the latest version of the code, get a copy of git, and
|
||||
|
||||
git clone git://git.torproject.org/git/tor .
|
||||
git clone https://git.torproject.org/git/tor
|
||||
|
||||
We talk about Tor on the tor-talk mailing list. Design proposals and
|
||||
discussion belong on the tor-dev mailing list. We hang around on
|
||||
|
|
@ -38,9 +38,9 @@ release. Occasionally, we'll merge an urgent bugfix into the release branch
|
|||
before it gets merged into maint, but that's rare.
|
||||
|
||||
If you're working on a bugfix for a bug that occurs in a particular version,
|
||||
base your bugfix branch on the "maint" branch for the first _actively
|
||||
developed_ series that has that bug. (Right now, that's 0.2.1.) If you're
|
||||
working on a new feature, base it on the master branch.
|
||||
base your bugfix branch on the "maint" branch for the first supported series
|
||||
that has that bug. (As of June 2013, we're supporting 0.2.3 and later.) If
|
||||
you're working on a new feature, base it on the master branch.
|
||||
|
||||
|
||||
How we log changes
|
||||
|
|
@ -51,7 +51,7 @@ the "changes" toplevel subdirectory. It should have the format of a
|
|||
one-entry changelog section from the current ChangeLog file, as in
|
||||
|
||||
o Major bugfixes:
|
||||
- Fix a potential buffer overflow. Fixes bug 9999; bugfix on
|
||||
- Fix a potential buffer overflow. Fixes bug 99999; bugfix on
|
||||
0.3.1.4-beta.
|
||||
|
||||
To write a changes file, first categorize the change. Some common categories
|
||||
|
|
@ -90,10 +90,10 @@ Useful tools
|
|||
These aren't strictly necessary for hacking on Tor, but they can help track
|
||||
down bugs.
|
||||
|
||||
The buildbot
|
||||
~~~~~~~~~~~~
|
||||
Jenkins
|
||||
~~~~~~~
|
||||
|
||||
https://buildbot.vidalia-project.net/one_line_per_build
|
||||
http://jenkins.torproject.org
|
||||
|
||||
Dmalloc
|
||||
~~~~~~~
|
||||
|
|
@ -182,6 +182,8 @@ Did you remember...
|
|||
|
||||
- To build your code while configured with --enable-gcc-warnings?
|
||||
- To run "make check-spaces" on your code?
|
||||
- To run "make check-docs" to see whether all new options are on
|
||||
the manpage?
|
||||
- To write unit tests, as possible?
|
||||
- To base your code on the appropriate branch?
|
||||
- To include a file in the "changes" directory as appropriate?
|
||||
|
|
@ -312,7 +314,7 @@ do your own profiling to determine otherwise.
|
|||
Log conventions
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#LogLevels
|
||||
https://trac.torproject.org/projects/tor/wiki/doc/TorFAQ#loglevel
|
||||
|
||||
No error or warning messages should be expected during normal OR or OP
|
||||
operation.
|
||||
|
|
|
|||
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.
|
||||
|
||||
|
|
@ -870,6 +870,9 @@ tor_lockfile_unlock(tor_lockfile_t *lockfile)
|
|||
/** @{ */
|
||||
/** Some old versions of Unix didn't define constants for these values,
|
||||
* and instead expect you to say 0, 1, or 2. */
|
||||
#ifndef SEEK_SET
|
||||
#define SEEK_SET 0
|
||||
#endif
|
||||
#ifndef SEEK_CUR
|
||||
#define SEEK_CUR 1
|
||||
#endif
|
||||
|
|
@ -900,6 +903,18 @@ tor_fd_seekend(int fd)
|
|||
#endif
|
||||
}
|
||||
|
||||
/** Move <b>fd</b> to position <b>pos</b> in the file. Return -1 on error, 0
|
||||
* on success. */
|
||||
int
|
||||
tor_fd_setpos(int fd, off_t pos)
|
||||
{
|
||||
#ifdef _WIN32
|
||||
return _lseek(fd, pos, SEEK_SET) < 0 ? -1 : 0;
|
||||
#else
|
||||
return lseek(fd, pos, SEEK_SET) < 0 ? -1 : 0;
|
||||
#endif
|
||||
}
|
||||
|
||||
#undef DEBUG_SOCKET_COUNTING
|
||||
#ifdef DEBUG_SOCKET_COUNTING
|
||||
/** A bitarray of all fds that should be passed to tor_socket_close(). Only
|
||||
|
|
|
|||
|
|
@ -411,6 +411,7 @@ tor_lockfile_t *tor_lockfile_lock(const char *filename, int blocking,
|
|||
void tor_lockfile_unlock(tor_lockfile_t *lockfile);
|
||||
|
||||
off_t tor_fd_getpos(int fd);
|
||||
int tor_fd_setpos(int fd, off_t pos);
|
||||
int tor_fd_seekend(int fd);
|
||||
|
||||
#ifdef _WIN32
|
||||
|
|
|
|||
|
|
@ -1711,8 +1711,7 @@ getinfo_helper_dir(control_connection_t *control_conn,
|
|||
const node_t *node = node_get_by_hex_id(question+strlen("md/id/"));
|
||||
const microdesc_t *md = NULL;
|
||||
if (node) md = node->md;
|
||||
if (md) {
|
||||
tor_assert(md->body);
|
||||
if (md && md->body) {
|
||||
*answer = tor_strndup(md->body, md->bodylen);
|
||||
}
|
||||
} else if (!strcmpstart(question, "md/name/")) {
|
||||
|
|
@ -1722,8 +1721,7 @@ getinfo_helper_dir(control_connection_t *control_conn,
|
|||
/* XXXX duplicated code */
|
||||
const microdesc_t *md = NULL;
|
||||
if (node) md = node->md;
|
||||
if (md) {
|
||||
tor_assert(md->body);
|
||||
if (md && md->body) {
|
||||
*answer = tor_strndup(md->body, md->bodylen);
|
||||
}
|
||||
} else if (!strcmpstart(question, "desc-annotations/id/")) {
|
||||
|
|
@ -3743,8 +3741,21 @@ control_event_stream_status(entry_connection_t *conn, stream_status_event_t tp,
|
|||
}
|
||||
|
||||
if (tp == STREAM_EVENT_NEW || tp == STREAM_EVENT_NEW_RESOLVE) {
|
||||
tor_snprintf(addrport_buf,sizeof(addrport_buf), " SOURCE_ADDR=%s:%d",
|
||||
ENTRY_TO_CONN(conn)->address, ENTRY_TO_CONN(conn)->port);
|
||||
/*
|
||||
* When the control conn is an AF_UNIX socket and we have no address,
|
||||
* it gets set to "(Tor_internal)"; see dnsserv_launch_request() in
|
||||
* dnsserv.c.
|
||||
*/
|
||||
if (strcmp(ENTRY_TO_CONN(conn)->address, "(Tor_internal)") != 0) {
|
||||
tor_snprintf(addrport_buf,sizeof(addrport_buf), " SOURCE_ADDR=%s:%d",
|
||||
ENTRY_TO_CONN(conn)->address, ENTRY_TO_CONN(conn)->port);
|
||||
} else {
|
||||
/*
|
||||
* else leave it blank so control on AF_UNIX doesn't need to make
|
||||
* something up.
|
||||
*/
|
||||
addrport_buf[0] = '\0';
|
||||
}
|
||||
} else {
|
||||
addrport_buf[0] = '\0';
|
||||
}
|
||||
|
|
|
|||
|
|
@ -3981,7 +3981,7 @@ connection_dirserv_add_microdescs_to_outbuf(dir_connection_t *conn)
|
|||
char *fp256 = smartlist_pop_last(conn->fingerprint_stack);
|
||||
microdesc_t *md = microdesc_cache_lookup_by_digest256(cache, fp256);
|
||||
tor_free(fp256);
|
||||
if (!md)
|
||||
if (!md || !md->body)
|
||||
continue;
|
||||
if (conn->zlib_state) {
|
||||
/* XXXX024 This 'last' business should actually happen on the last
|
||||
|
|
|
|||
|
|
@ -183,8 +183,23 @@ dnsserv_launch_request(const char *name, int reverse,
|
|||
conn->base_.state = AP_CONN_STATE_RESOLVE_WAIT;
|
||||
|
||||
tor_addr_copy(&TO_CONN(conn)->addr, &control_conn->base_.addr);
|
||||
#ifdef AF_UNIX
|
||||
/*
|
||||
* The control connection can be AF_UNIX and if so tor_dup_addr will
|
||||
* unhelpfully say "<unknown address type>"; say "(Tor_internal)"
|
||||
* instead.
|
||||
*/
|
||||
if (control_conn->base_.socket_family == AF_UNIX) {
|
||||
TO_CONN(conn)->port = 0;
|
||||
TO_CONN(conn)->address = tor_strdup("(Tor_internal)");
|
||||
} else {
|
||||
TO_CONN(conn)->port = control_conn->base_.port;
|
||||
TO_CONN(conn)->address = tor_dup_addr(&control_conn->base_.addr);
|
||||
}
|
||||
#else
|
||||
TO_CONN(conn)->port = control_conn->base_.port;
|
||||
TO_CONN(conn)->address = tor_dup_addr(&control_conn->base_.addr);
|
||||
#endif
|
||||
|
||||
if (reverse)
|
||||
entry_conn->socks_request->command = SOCKS_COMMAND_RESOLVE_PTR;
|
||||
|
|
|
|||
|
|
@ -74,7 +74,11 @@ static ssize_t
|
|||
dump_microdescriptor(int fd, microdesc_t *md, size_t *annotation_len_out)
|
||||
{
|
||||
ssize_t r = 0;
|
||||
size_t written;
|
||||
ssize_t written;
|
||||
if (md->body == NULL) {
|
||||
*annotation_len_out = 0;
|
||||
return 0;
|
||||
}
|
||||
/* XXXX drops unknown annotations. */
|
||||
if (md->last_listed) {
|
||||
char buf[ISO_TIME_LEN+1];
|
||||
|
|
@ -95,10 +99,10 @@ dump_microdescriptor(int fd, microdesc_t *md, size_t *annotation_len_out)
|
|||
|
||||
md->off = tor_fd_getpos(fd);
|
||||
written = write_all(fd, md->body, md->bodylen, 0);
|
||||
if (written != md->bodylen) {
|
||||
if (written != (ssize_t)md->bodylen) {
|
||||
log_warn(LD_DIR,
|
||||
"Couldn't dump microdescriptor (wrote %lu out of %lu): %s",
|
||||
(unsigned long)written, (unsigned long)md->bodylen,
|
||||
"Couldn't dump microdescriptor (wrote %ld out of %lu): %s",
|
||||
(long)written, (unsigned long)md->bodylen,
|
||||
strerror(errno));
|
||||
return -1;
|
||||
}
|
||||
|
|
@ -447,13 +451,20 @@ microdesc_cache_rebuild(microdesc_cache_t *cache, int force)
|
|||
HT_FOREACH(mdp, microdesc_map, &cache->map) {
|
||||
microdesc_t *md = *mdp;
|
||||
size_t annotation_len;
|
||||
if (md->no_save)
|
||||
if (md->no_save || !md->body)
|
||||
continue;
|
||||
|
||||
size = dump_microdescriptor(fd, md, &annotation_len);
|
||||
if (size < 0) {
|
||||
/* XXX handle errors from dump_microdescriptor() */
|
||||
/* log? return -1? die? coredump the universe? */
|
||||
if (md->saved_location != SAVED_IN_CACHE)
|
||||
tor_free(md->body);
|
||||
md->saved_location = SAVED_NOWHERE;
|
||||
md->off = 0;
|
||||
md->bodylen = 0;
|
||||
md->no_save = 1;
|
||||
|
||||
/* rewind, in case it was a partial write. */
|
||||
tor_fd_setpos(fd, off);
|
||||
continue;
|
||||
}
|
||||
tor_assert(((size_t)size) == annotation_len + md->bodylen);
|
||||
|
|
@ -474,15 +485,29 @@ microdesc_cache_rebuild(microdesc_cache_t *cache, int force)
|
|||
smartlist_add(wrote, md);
|
||||
}
|
||||
|
||||
/* We must do this unmap _before_ we call finish_writing_to_file(), or
|
||||
* windows will not actually replace the file. */
|
||||
if (cache->cache_content)
|
||||
tor_munmap_file(cache->cache_content);
|
||||
|
||||
if (finish_writing_to_file(open_file) < 0) {
|
||||
log_warn(LD_DIR, "Error rebuilding microdescriptor cache: %s",
|
||||
strerror(errno));
|
||||
/* Okay. Let's prevent from making things worse elsewhere. */
|
||||
cache->cache_content = NULL;
|
||||
HT_FOREACH(mdp, microdesc_map, &cache->map) {
|
||||
microdesc_t *md = *mdp;
|
||||
if (md->saved_location == SAVED_IN_CACHE) {
|
||||
md->off = 0;
|
||||
md->saved_location = SAVED_NOWHERE;
|
||||
md->body = NULL;
|
||||
md->bodylen = 0;
|
||||
md->no_save = 1;
|
||||
}
|
||||
}
|
||||
return -1;
|
||||
}
|
||||
|
||||
if (cache->cache_content)
|
||||
tor_munmap_file(cache->cache_content);
|
||||
|
||||
cache->cache_content = tor_mmap_file(cache->cache_fname);
|
||||
|
||||
if (!cache->cache_content && smartlist_len(wrote)) {
|
||||
|
|
|
|||
|
|
@ -541,6 +541,8 @@ typedef enum {
|
|||
#define CIRCUIT_PURPOSE_IS_ESTABLISHED_REND(p) \
|
||||
((p) == CIRCUIT_PURPOSE_C_REND_JOINED || \
|
||||
(p) == CIRCUIT_PURPOSE_S_REND_JOINED)
|
||||
/** True iff the circuit_t c is actually an or_circuit_t */
|
||||
#define CIRCUIT_IS_ORCIRC(c) (((circuit_t *)(c))->magic == OR_CIRCUIT_MAGIC)
|
||||
|
||||
/** How many circuits do we want simultaneously in-progress to handle
|
||||
* a given stream? */
|
||||
|
|
@ -818,6 +820,13 @@ typedef enum {
|
|||
/** Amount to increment a stream window when we get a stream SENDME. */
|
||||
#define STREAMWINDOW_INCREMENT 50
|
||||
|
||||
/** Maximum number of queued cells on a circuit for which we are the
|
||||
* midpoint before we give up and kill it. This must be >= circwindow
|
||||
* to avoid killing innocent circuits, and >= circwindow*2 to give
|
||||
* leaky-pipe a chance for being useful someday.
|
||||
*/
|
||||
#define ORCIRC_MAX_MIDDLE_CELLS (21*(CIRCWINDOW_START_MAX)/10)
|
||||
|
||||
/* Cell commands. These values are defined in tor-spec.txt. */
|
||||
#define CELL_PADDING 0
|
||||
#define CELL_CREATE 1
|
||||
|
|
|
|||
|
|
@ -2466,8 +2466,10 @@ append_cell_to_circuit_queue(circuit_t *circ, channel_t *chan,
|
|||
cell_t *cell, cell_direction_t direction,
|
||||
streamid_t fromstream)
|
||||
{
|
||||
or_circuit_t *orcirc = NULL;
|
||||
cell_queue_t *queue;
|
||||
int streams_blocked;
|
||||
|
||||
if (circ->marked_for_close)
|
||||
return;
|
||||
|
||||
|
|
@ -2475,11 +2477,35 @@ append_cell_to_circuit_queue(circuit_t *circ, channel_t *chan,
|
|||
queue = &circ->n_chan_cells;
|
||||
streams_blocked = circ->streams_blocked_on_n_chan;
|
||||
} else {
|
||||
or_circuit_t *orcirc = TO_OR_CIRCUIT(circ);
|
||||
orcirc = TO_OR_CIRCUIT(circ);
|
||||
queue = &orcirc->p_chan_cells;
|
||||
streams_blocked = circ->streams_blocked_on_p_chan;
|
||||
}
|
||||
|
||||
/* Are we a middle circuit about to exceed ORCIRC_MAX_MIDDLE_CELLS? */
|
||||
if ((circ->n_chan != NULL) && CIRCUIT_IS_ORCIRC(circ)) {
|
||||
orcirc = TO_OR_CIRCUIT(circ);
|
||||
if (orcirc->p_chan) {
|
||||
if (queue->n + 1 >= ORCIRC_MAX_MIDDLE_CELLS) {
|
||||
/* Queueing this cell would put queue over the cap */
|
||||
log_warn(LD_CIRC,
|
||||
"Got a cell exceeding the cap of %u in the %s direction "
|
||||
"on middle circ ID %u on chan ID " U64_FORMAT
|
||||
"; killing the circuit.",
|
||||
ORCIRC_MAX_MIDDLE_CELLS,
|
||||
(direction == CELL_DIRECTION_OUT) ? "n" : "p",
|
||||
(direction == CELL_DIRECTION_OUT) ?
|
||||
circ->n_circ_id : orcirc->p_circ_id,
|
||||
U64_PRINTF_ARG(
|
||||
(direction == CELL_DIRECTION_OUT) ?
|
||||
circ->n_chan->global_identifier :
|
||||
orcirc->p_chan->global_identifier));
|
||||
circuit_mark_for_close(circ, END_CIRC_REASON_RESOURCELIMIT);
|
||||
return;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
cell_queue_append_packed_copy(queue, cell, chan->wide_circ_ids);
|
||||
|
||||
/* If we have too many cells on the circuit, we should stop reading from
|
||||
|
|
|
|||
|
|
@ -208,11 +208,25 @@ test_md_cache(void *data)
|
|||
md3 = NULL; /* it's history now! */
|
||||
|
||||
/* rebuild again, make sure it stays gone. */
|
||||
microdesc_cache_rebuild(mc, 1);
|
||||
tt_int_op(microdesc_cache_rebuild(mc, 1), ==, 0);
|
||||
tt_ptr_op(md1, ==, microdesc_cache_lookup_by_digest256(mc, d1));
|
||||
tt_ptr_op(md2, ==, microdesc_cache_lookup_by_digest256(mc, d2));
|
||||
tt_ptr_op(NULL, ==, microdesc_cache_lookup_by_digest256(mc, d3));
|
||||
|
||||
/* Re-add md3, and make sure we can rebuild the cache. */
|
||||
added = microdescs_add_to_cache(mc, test_md3_noannotation, NULL,
|
||||
SAVED_NOWHERE, 0, time3, NULL);
|
||||
tt_int_op(1, ==, smartlist_len(added));
|
||||
md3 = smartlist_get(added, 0);
|
||||
smartlist_free(added);
|
||||
added = NULL;
|
||||
tt_int_op(md1->saved_location, ==, SAVED_IN_CACHE);
|
||||
tt_int_op(md2->saved_location, ==, SAVED_IN_CACHE);
|
||||
tt_int_op(md3->saved_location, ==, SAVED_IN_JOURNAL);
|
||||
|
||||
tt_int_op(microdesc_cache_rebuild(mc, 1), ==, 0);
|
||||
tt_int_op(md3->saved_location, ==, SAVED_IN_CACHE);
|
||||
|
||||
done:
|
||||
if (options)
|
||||
tor_free(options->DataDirectory);
|
||||
|
|
|
|||
Loading…
Reference in New Issue