Tor 0.2.2.17-alpha is out
Tor 0.2.2.17-alpha introduces a feature to make it harder for clients to use one-hop circuits (which can put the exit relays at higher risk, plus unbalance the network); fixes a big bug in bandwidth accounting for relays that want to limit their monthly bandwidth use; fixes a big pile of bugs in how clients tolerate temporary network failure; and makes our adaptive circuit build timeout feature (which improves client performance if your network is fast while not breaking things if your network is slow) better handle bad networks.
https://www.torproject.org/download.html.en
Packages will be appearing over the next few days.
The original announcement is http://archives.seul.org/or/talk/Oct-2010/msg00001.html
Changes in version 0.2.2.17-alpha - 2010-09-30
o Major features:
- Exit relays now try harder to block exit attempts from unknown
relays, to make it harder for people to use them as one-hop proxies
a la tortunnel. Controlled by the refuseunknownexits consensus
parameter (currently enabled), or you can override it on your
relay with the RefuseUnknownExits torrc option. Resolves bug 1751.o Major bugfixes (0.2.1.x and earlier):
- Fix a bug in bandwidth accounting that could make us use twice
the intended bandwidth when our interval start changes due to
daylight saving time. Now we tolerate skew in stored vs computed
interval starts: if the start of the period changes by no more than
50% of the period's duration, we remember bytes that we transferred
in the old period. Fixes bug 1511; bugfix on 0.0.9pre5.
- Always search the Windows system directory for system DLLs, and
nowhere else. Bugfix on 0.1.1.23; fixes bug 1954.
- When you're using bridges and your network goes away and your
bridges get marked as down, recover when you attempt a new socks
connection (if the network is back), rather than waiting up to an
hour to try fetching new descriptors for your bridges. Bugfix on
0.2.0.3-alpha; fixes bug 1981.o Major bugfixes (on 0.2.2.x):
- Fix compilation on Windows. Bugfix on 0.2.2.16-alpha; related to
bug 1797.
- Fix a segfault that could happen when operating a bridge relay with
no GeoIP database set. Fixes bug 1964; bugfix on 0.2.2.15-alpha.
- The consensus bandwidth-weights (used by clients to choose fast
relays) entered an unexpected edge case in September where
Exits were much scarcer than Guards, resulting in bad weight
recommendations. Now we compute them using new constraints that
should succeed in all cases. Also alter directory authorities to
not include the bandwidth-weights line if they fail to produce
valid values. Fixes bug 1952; bugfix on 0.2.2.10-alpha.
- When weighting bridges during path selection, we used to trust
the bandwidths they provided in their descriptor, only capping them
at 10MB/s. This turned out to be problematic for two reasons:
Bridges could claim to handle a lot more traffic then they
actually would, thus making more clients pick them and have a
pretty effective DoS attack. The other issue is that new bridges
that might not have a good estimate for their bw capacity yet
would not get used at all unless no other bridges are available
to a client. Fixes bug 1912; bugfix on 0.2.2.7-alpha.o Major bugfixes (on the circuit build timeout feature, 0.2.2.x):
- Ignore cannibalized circuits when recording circuit build times.
This should provide for a minor performance improvement for hidden
service users using 0.2.2.14-alpha, and should remove two spurious
notice log messages. Bugfix on 0.2.2.14-alpha; fixes bug 1740.
- Simplify the logic that causes us to decide if the network is
unavailable for purposes of recording circuit build times. If we
receive no cells whatsoever for the entire duration of a circuit's
full measured lifetime, the network is probably down. Also ignore
one-hop directory fetching circuit timeouts when calculating our
circuit build times. These changes should hopefully reduce the
cases where we see ridiculous circuit build timeouts for people
with spotty wireless connections. Fixes part of bug 1772; bugfix
on 0.2.2.2-alpha.
- Prevent the circuit build timeout from becoming larger than
the maximum build time we have ever seen. Also, prevent the time
period for measurement circuits from becoming larger than twice that
value. Fixes the other part of bug 1772; bugfix on 0.2.2.2-alpha.o Minor features:
- When we run out of directory information such that we can't build
circuits, but then get enough that we can build circuits, log when
we actually construct a circuit, so the user has a better chance of
knowing what's going on. Fixes bug 1362.
- Be more generous with how much bandwidth we'd use up (with
accounting enabled) before entering "soft hibernation". Previously,
we'd refuse new connections and circuits once we'd used up 95% of
our allotment. Now, we use up 95% of our allotment, AND make sure
that we have no more than 500MB (or 3 hours of expected traffic,
whichever is lower) remaining before we enter soft hibernation.
- If we've configured EntryNodes and our network goes away and/or all
our entrynodes get marked down, optimistically retry them all when
a new socks application request appears. Fixes bug 1882.
- Add some more defensive programming for architectures that can't
handle unaligned integer accesses. We don't know of any actual bugs
right now, but that's the best time to fix them. Fixes bug 1943.
- Support line continuations in the torrc config file. If a line
ends with a single backslash character, the newline is ignored, and
the configuration value is treated as continuing on the next line.
Resolves bug 1929.o Minor bugfixes (on 0.2.1.x and earlier):
- For bandwidth accounting, calculate our expected bandwidth rate
based on the time during which we were active and not in
soft-hibernation during the last interval. Previously, we were
also considering the time spent in soft-hibernation. If this
was a long time, we would wind up underestimating our bandwidth
by a lot, and skewing our wakeup time towards the start of the
accounting interval. Fixes bug 1789. Bugfix on 0.0.9pre5.o Minor bugfixes (on 0.2.2.x):
- Resume generating CIRC FAILED REASON=TIMEOUT control port messages,
which were disabled by the circuit build timeout changes in
0.2.2.14-alpha. Bugfix on 0.2.2.14-alpha; fixes bug 1739.
- Make sure we don't warn about missing bandwidth weights when
choosing bridges or other relays not in the consensus. Bugfix on
0.2.2.10-alpha; fixes bug 1805.
- In our logs, do not double-report signatures from unrecognized
authorities both as "from unknown authority" and "not
present". Fixes bug 1956, bugfix on 0.2.2.16-alpha.
Comments
Please note that the comment area below has been archived.
Hi phobos!!!!!!!!!!!!! I've
Hi phobos!!!!!!!!!!!!!
I've a question!!!!!!!!!!!!!!!!!!!!! I don't understand this!!!!!!!! Tor "introduces a feature to make it harder for clients to use one-hop circuits (which can put the exit relays at higher risk", so, i would like to know!!! one-hop circuits put the exit relays at a higher risk of what?!!!!!!!!!!!!! Because it doesn't make sense to me!!!!!!!!
bye!!!!!!!!
~bee!!!!!!
Why ? !!!! The need !!!! for
Why ? !!!! The need !!!! for all the exclamation marks !!!!!!!
:-)
In this version did you fix
In this version did you fix the 30MB limit bug? If not where can i get older releases of Vidalia+privoxy? Thank you.
As far as I know this bug is
As far as I know this bug is unrelated to tor. It is a limitation within Polipo, but you can use privoxy instead. It has no limits.
Love you guys and appreciate
Love you guys and appreciate Tor very much but I just need a quick start up guide to get it configured and running good enough for basic troll protection on forums -- I really don't need to wade through all those fascinating geeky tidbits on the wiki front page.
You could call it "click here for the quick start up guide". LOL :)
For example, the first time I downloaded Tor/vidalia/firefox, it worked perfectly right out of the box without my doing anything at all (checked my ip with those reverse look up sites) and browsing the net was only a tiny bit slower than normal. But then I got the bright idea to disable Tor, and haven't been able to get it running again even after uninstalling Tor/vidalia/firefox and reinstalling.
I don't know where to START, and reading the Wiki novel just to find a simple set of instructions seems redundant.
this is why we push the tor
this is why we push the tor browser bundle, it's preconfigured and for 99.99% of people works every time.
Oh gosh thanks for replying
Oh gosh thanks for replying so quickly. But I did download the Tor bundle! lol It worked perfectly right out of the box without my doing anything at all -- literally. Which is why I'm so confused why it doesn't work now.
All I did was click on that button in the bottom right screen to disable Tor temporarily, and when I tried to enable it again, it wouldn't work no matter what I did.
The error message which appears in the firefox window is:
The proxy server is refusing connections
Firefox is configured to use a proxy server that is refusing connections.
* Check the proxy settings to make sure that they are correct.
* Contact your network administrator to make sure the proxy server is working.
All I really need to know (I think) is what to type into the Tor preferences screen.
Anyway, you guys are awesome, seriously. Hate to waste anyone's time... but a quick start up guide.... please?
Tor 0.2.2.17-alpha is much
Tor 0.2.2.17-alpha is much faster on my laptop than Tor 0.2.2.15-alpha. Thanks.
in stable win bundle version
in stable win bundle version 0.2.1.26-0.2.10.exe the command
"tor -?" shows v0.2.2.15-alpha!
where is 0.2.1.26?
Anyone else experiencing
Anyone else experiencing server (as middleman) crashes on Debian?
Hello, Just to let you know
Hello,
Just to let you know that I have just tried using the TOR Browser Bundle with Vista/Firefox 3.6.10 and surprisingly, (this time) it actually worked. However there was no mention that all plugins are disabled so that you cannot watch even a video. It would have saved me a few hours if you had mentioned it upfront.
Even worse than that is the fact that all anonymity is lost should you ever (gasp) watch a video or use any plugin ! What a joke !
A little flaw in the TOR system if you ask me because it renders it useless. I mean, you have gone to extensive lengths to successfully stay anonymous, and congratulations on that, but one single flash file and it is all rendered useless.
By the way, for people who cannot provide an anonymous system I would not try and be patronising with the :
“Then read "How to ask questions the smart way"
It just make you look even more silly.
Your “contact us” section is just like TOR. You run around in rings getting nowhere.
Ta
Super
The warning is on the
The warning is on the download page in a different color box, with a red warning icon next to it. Flash is a binary blob that the user cannot control. It can have access to system resources and do just about whatever it wants, and send data to wherever it wants. Tor is forced to block it to protect you. Tor protects you just fine. Unfortunately operating systems are designed to share your data with anything that asks, regardless of what the user wants it to share.
You know what. You could
You know what. You could design a system where Flash is relatively safe to use. And for the user it would be a tool that takes allot more work to utilize if it works (it might work for 75-85% of the users or partly for 95%). I'm not going to pretend any non-free (as in freedom) system is safe though because you are right. You don't have the source code. It isn't. Although if you set it up just right... the flash plug-in wouldn't be able to get your external IP address and would be rendered quite harmless for all practical purposes. What it would be sending over Tor and revealing to any malicious party would be an internal IP address. Totally useless to identify you. It takes allot more work to get right though.
Do fix 30MB limit bug as
Do fix 30MB limit bug as soon as possible! Thank's in advance
Does anyone know... When I
Does anyone know...
When I compile on Windows under MinGW I get a Tor executable that is overt 6mb !!!
Is there some optimisation flag I am missing ?
The main developers manage to produce an executable that is only 2mb.
Scratching my head here...
We compile in msys on winxp.
We compile in msys on winxp. what options are you including and have you tried to strip the exe?
Hi Phobos, thanks for
Hi Phobos, thanks for getting back on this one.
I hope they are paying you for all this support !
I dont include any options per se on the build.
I effectively issue a make against the code and out pops the EXE.
I dont know how to strip an EXE so I guess mine is fully clothed ;-)
How do I strip it ? That sounds like a potential solution here since its new to me.
The flags I see in the makefile are:
CFLAGS = -g -O2 -Wall -g -O2 -fno-strict-aliasing
Thats all i guess..
Thanks in advance !
Cav Edwards
in msys, "strip tor.exe"
in msys, "strip tor.exe"
Fantastic... thats done the
Fantastic... thats done the trick !
Many thanks.
OMG! even Tor 0.2.2.17-alpha
OMG! even Tor 0.2.2.17-alpha DOESN'T SUPPORT downloading files large than 30MB! JESUS CHRIST you are not able fix this primitive bug?! What are you waiting for? Christmass?
It's not a tor problem, it's
It's not a tor problem, it's a polipo issue. And no, we aren't able to fix it easily because 99% of the time there is no bug to report. If you can reliably recreate the issue, open a ticket, https://trac.torproject.org/.
Why in Vidalia Bundle and in
Why in Vidalia Bundle and in Tor Browser the tor.exe have different sizes?