Tor 0.2.2.18-alpha available

Tor 0.2.2.18-alpha fixes several crash bugs that have been nagging us lately, makes unpublished bridge relays able to detect their IP address, and fixes a wide variety of other bugs to get us much closer to a stable release.

https://www.torproject.org/download/download

Packages will be appearing over the next few days. The original version of this announcement is at http://archives.seul.org/or/talk/Nov-2010/msg00082.html.

Changes in version 0.2.2.18-alpha - 2010-11-16
o Major bugfixes:
- Do even more to reject (and not just ignore) annotations on
router descriptors received anywhere but from the cache. Previously
we would ignore such annotations at first, but cache them to disk
anyway. Bugfix on 0.2.0.8-alpha. Found by piebeer.
- Do not log messages to the controller while shrinking buffer
freelists. Doing so would sometimes make the controller connection
try to allocate a buffer chunk, which would mess up the internals
of the freelist and cause an assertion failure. Fixes bug 1125;
fixed by Robert Ransom. Bugfix on 0.2.0.16-alpha.
- Learn our external IP address when we're a relay or bridge, even if
we set PublishServerDescriptor to 0. Bugfix on 0.2.0.3-alpha,
where we introduced bridge relays that don't need to publish to
be useful. Fixes bug 2050.
- Maintain separate TLS contexts and certificates for incoming and
outgoing connections in bridge relays. Previously we would use the
same TLS contexts and certs for incoming and outgoing connections.
Bugfix on 0.2.0.3-alpha; addresses bug 988.
- Maintain separate identity keys for incoming and outgoing TLS
contexts in bridge relays. Previously we would use the same
identity keys for incoming and outgoing TLS contexts. Bugfix on
0.2.0.3-alpha; addresses the other half of bug 988.
- Avoid an assertion failure when we as an authority receive a
duplicate upload of a router descriptor that we already have,
but which we previously considered an obsolete descriptor.
Fixes another case of bug 1776. Bugfix on 0.2.2.16-alpha.
- Avoid a crash bug triggered by looking at a dangling pointer while
setting the network status consensus. Found by Robert Ransom.
Bugfix on 0.2.2.17-alpha. Fixes bug 2097.
- Fix a logic error where servers that _didn't_ act as exits would
try to keep their server lists more aggressively up to date than
exits, when it was supposed to be the other way around. Bugfix
on 0.2.2.17-alpha.

o Minor bugfixes (on Tor 0.2.1.x and earlier):
- When we're trying to guess whether we know our IP address as
a relay, we would log various ways that we failed to guess
our address, but never log that we ended up guessing it
successfully. Now add a log line to help confused and anxious
relay operators. Bugfix on 0.1.2.1-alpha; fixes bug 1534.
- Bring the logic that gathers routerinfos and assesses the
acceptability of circuits into line. This prevents a Tor OP from
getting locked in a cycle of choosing its local OR as an exit for a
path (due to a .exit request) and then rejecting the circuit because
its OR is not listed yet. It also prevents Tor clients from using an
OR running in the same instance as an exit (due to a .exit request)
if the OR does not meet the same requirements expected of an OR
running elsewhere. Fixes bug 1859; bugfix on 0.1.0.1-rc.
- Correctly describe errors that occur when generating a TLS object.
Previously we would attribute them to a failure while generating a
TLS context. Patch by Robert Ransom. Bugfix on 0.1.0.4-rc; fixes
bug 1994.
- Enforce multiplicity rules when parsing annotations. Bugfix on
0.2.0.8-alpha. Found by piebeer.
- Fix warnings that newer versions of autoconf produced during
./autogen.sh. These warnings appear to be harmless in our case,
but they were extremely verbose. Fixes bug 2020.

o Minor bugfixes (on Tor 0.2.2.x):
- Enable protection of small arrays whenever we build with gcc
hardening features, not only when also building with warnings
enabled. Fixes bug 2031; bugfix on 0.2.2.14-alpha. Reported by keb.

o Minor features:
- Make hidden services work better in private Tor networks by not
requiring any uptime to join the hidden service descriptor
DHT. Implements ticket 2088.
- Rate-limit the "your application is giving Tor only an IP address"
warning. Addresses bug 2000; bugfix on 0.0.8pre2.
- When AllowSingleHopExits is set, print a warning to explain to the
relay operator why most clients are avoiding her relay.
- Update to the November 1 2010 Maxmind GeoLite Country database.

o Code simplifications and refactoring:
- When we fixed bug 1038 we had to put in a restriction not to send
RELAY_EARLY cells on rend circuits. This was necessary as long
as relays using Tor 0.2.1.3-alpha through 0.2.1.18-alpha were
active. Now remove this obsolete check. Resolves bug 2081.
- Some options used different conventions for uppercasing of acronyms
when comparing manpage and source. Fix those in favor of the
manpage, as it makes sense to capitalize acronyms.
- Remove the torrc.complete file. It hasn't been kept up to date
and users will have better luck checking out the manpage.
- Remove the obsolete "NoPublish" option; it has been flagged
as obsolete and has produced a warning since 0.1.1.18-rc.
- Remove everything related to building the expert bundle for OS X.
It has confused many users, doesn't work right on OS X 10.6,
and is hard to get rid of once installed. Resolves bug 1274.

Read the final paragraph:

"Remove everything related to building the expert bundle for OS X. It has confused many users, doesn't work right on OS X 10.6, and is hard to get rid of once installed. Resolves bug 1274."

Don't hold your breath for something they've decided to stop providing.

Anonymous

November 19, 2010

Permalink

Hi Anon, you can get any package you desire from: http://www.torproject.org/dist/

This version of Tor is running very well here, with:
openssl-1.0.0b
zlib-1.2.5
libevent-2.0.8-rc

Fronted by...
polipo-1.0.4.1

I'm a very very happy customer... :-)

Anonymous

November 19, 2010

Permalink

I use windows 2000 i cant use the new versions of TOR, i dondt no why is not well funktion. Can some one tell me what i must download that i can use the new version?

There was information posted in this thread off the main page some time ago:
https://blog.torproject.org/blog/vidalia-0210-released#comments

There was help for win2k users also posted, by phobos:
"""
Vidalia doesn't work in Win2k because of a winsock dll bug in Win2K.

The explanation for it here:

http://msdn.microsoft.com/en-us/library/ms737931

If you don't want to recompile Vidalia yourself, this site offers a replacement
dll (with source) that appears to work:

http://codemagnet.blogspot.com/2007/10/winsock2-replacement.html
http://martin.brenner.de/files/winsock2_getaddrinfo.rar
"""

I hope this helps... please update this thread on your progress.

Basically, Win2k can work with the Tor stack it seems.

Anonymous

November 21, 2010

Permalink

i couldn't find the installer !!!!!!!!!

it's not in the package

Anonymous

November 25, 2010

Permalink

Anyone know if theres an option in tor i would call it "dynamic exclude list" so it would exclude exit/entry/middle nodes during seeting up new circuits based on specific cryteria, like circuit uptime, connected ips, idle time etc.

Anonymous

November 27, 2010

Permalink

Hello. This is OT, and I apologize in advance. I'm certain that everyone on here is by now aware that US DHS has begun "seizing" (their word) web sites by rewriting the site DNS records to point to an IP address of their choosing. They claim to be doing this because of copyright violations, but there is every reason to suspect that this is just the beginning of web censorship by US authorities of sites they deem objectionable (5 gets you 10 the next target is wikileaks.org). While this does not impact the function and purpose of Tor per se, there is little point in a tool that provides anonymous access to only non-controversial sites. So, my questions are: 1] is there any aspect of Tor (alternate DNS, etc.) that renders its users less affected by this tactic; 2] Is there any pre-existing non-Tor-project DNS alternative that could be used to circumvent this; 3] Is there any alternative strategy based on technology that exists as part of or because of the Tor project that could be quickly pressed into service to circumvent it? Any other recommendations or observations are welcome. I have begun archiving DNS records for sites that I value that I think could be next on DHS' hit list for my own use, but this really is an issue to which the only possible effective response will be a group effort of some kind. Thank you.