Nick Mathewson [Thu, 8 Mar 2012 20:42:54 +0000 (15:42 -0500)]
Require a threshold of exit nodes before building circuits
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.
Sebastian Hahn [Thu, 9 Feb 2012 23:51:58 +0000 (00:51 +0100)]
Properly protect paths to sed, sha1sum, openssl
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)
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.
Nick Mathewson [Tue, 27 Dec 2011 21:41:25 +0000 (16:41 -0500)]
Bug 4786 fix: don't convert EARLY to RELAY on v1 connections
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).
Nick Mathewson [Wed, 28 Dec 2011 02:47:04 +0000 (21:47 -0500)]
Authorities reject insecure Tors.
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 [Mon, 19 Dec 2011 19:37:52 +0000 (14:37 -0500)]
Do not even try to keep going on a socket with socklen==0
Back in #1240, r1eo linked to information about how this could happen
with older Linux kernels in response to nmap. Bugs #4545 and #4547
are about how our approach to trying to deal with this condition was
broken and stupid. Thanks to wanoskarnet for reminding us about #1240.
This is a fix for the abovementioned bugs, and is a bugfix on
0.1.0.3-rc.
Sebastian Hahn [Mon, 12 Dec 2011 14:36:08 +0000 (15:36 +0100)]
Build with warnings and clang 3.0
--enable-gcc-warnings enables two warnings that clang doesn't support,
so the build fails. We had hoped clang 3.0 would add those, but it
didn't, so let's just always disable those warnings when building with
clang. We can still fix it later once they add support
Sebastian Hahn [Fri, 18 Nov 2011 23:50:03 +0000 (00:50 +0100)]
Don't log about stats when running as a client without geoip
Completely disable stats if we aren't running as a relay. We won't
collect any anyway, so setting up the infrastructure for them and
logging about them is wrong. This also removes a confusing log
message that clients without a geoip db would have seen.
Nick Mathewson [Mon, 14 Nov 2011 22:46:43 +0000 (17:46 -0500)]
Use the EVENT_BASE_FLAG_NOLOCK flag to prevent socketpair() invocation
In Tor 0.2.2, we never need the event base to be notifiable, since we
don't call it from other threads. This is a workaround for bug 4457,
which is not actually a Tor bug IMO.
Nick Mathewson [Wed, 9 Nov 2011 17:08:28 +0000 (12:08 -0500)]
Correct the handling of overflow behavior in smartlist_ensure_capacity
The old behavior was susceptible to the compiler optimizing out our
assertion check, *and* could still overflow size_t on 32-bit systems
even when it did work.
Robert Ransom [Tue, 25 Oct 2011 19:33:21 +0000 (12:33 -0700)]
Add option to give guard flag to relays without the CVE-2011-2768 fix
This way, all of the DA operators can upgrade immediately, without nuking
every client's set of entry guards as soon as a majority of them upgrade.
Until enough guards have upgraded, a majority of dirauths should set this
config option so that there are still enough guards in the network. After
a few days pass, all dirauths should use the default.
Nick Mathewson [Mon, 23 May 2011 20:59:41 +0000 (16:59 -0400)]
Remove the -F option from tor-resolve.
It used to mean "Force": it would tell tor-resolve to ask tor to
resolve an address even if it ended with .onion. But when
AutomapHostsOnResolve was added, automatically refusing to resolve
.onion hosts stopped making sense. So in 0.2.1.16-rc (commit 298dc95dfd8), we made tor-resolve happy to resolve anything.
The -F option stayed in, though, even though it didn't do anything.
Oddly, it never got documented.
Found while fixing GCC 4.6 "set, unused variable" warnings.
projects / thirdparty / tor.git / log
