Roger explains at
http://archives.seul.org/tor/talk/Nov-2011/msg00209.html :
"If you list your bridge as part of your family in the relay
descriptor, then everybody can learn your bridge fingerprint, and
they can look up your bridge's descriptor (and thus location) at
the bridge directory authority."
Now, we can't stop relays from listing bridges, but we can warn when
we notice a bridge listing anybody, which might help some.
This fixes bug 4657; it's a fix on 0.2.0.3-alpha, where bridges were
first introduced.
The underlying strtoX functions handle overflow by saturating and
setting errno to ERANGE. If the min/max arguments to the
tor_parse_* functions are equal to the minimum/maximum of the
underlying type, then with the old approach, we wouldn't treat a
too-large value as genuinely broken.
Found this while looking at bug 5786; bugfix on 19da1f36 (in Tor
0.0.9), which introduced these functions.
This fixes a side-channel attack on the (fortunately unused!)
BridgePassword option for bridge authorities. Fix for bug 5543;
bugfix on 0.2.0.14-alpha.
This mitigates an attack proposed by wanoskarnet, in which all of a
client's bridges collude to restrict the exit nodes that the client
knows about. Fixes bug 5343.
in Makefile.am, we used it without quoting it, causing build failure if
your openssl/sed/sha1sum happened to live in a directory with a space in
it (very common on windows)
This reverts commit 55e8cae815.
The conversation from irc:
> weasel: i had intended to leave torrc.sample.in alone in maint-0.2.2,
since i don't want to make all your stable users have to deal with
a torrc change. but nickm changed it. is it in fact the case that a
change in that file means a change in the deb?
<weasel> it means you'll prompt every single user who ever touched
their torrc
<weasel> and they will be asked if they like your new version better
than what they have right now
<weasel> so it's not great
Instead I changed the website to redirect requests for the tor-manual
URL listed in maint-0.2.2's torrc.sample.in so the link will still work.
We used to do this as a workaround for older Tors, but now it's never
the correct thing to do (especially since anything that didn't
understand RELAY_EARLY is now deprecated hard).
This patch should make us reject every Tor that was vulnerable to
CVE-2011-0427. Additionally, it makes us reject every Tor that couldn't
handle RELAY_EARLY cells, which helps with proposal 110 (#4339).
Nick Mathewson
Ravi Chandra Padmala
Karsten Loesing
George Kadianakis
Sebastian Hahn
Roger Dingledine