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.
If we don't do this, [::] can be interpreted to mean all v4 and all
v6 addresses. Found by dcf. Fixes bug 4760. See RFC 3493 section
5.3 for more info.
There was one MS_WINDOWS that remained because it wasn't on a macro
line; a few remaining uses (and the definition!) in configure.in;
and a now-nonsensical stanza of eventdns_tor.h that previously
defined 'WIN32' if it didn't exist.
Previously the client would ask the bridge for microdescriptors, which are
only supported in 0.2.3.x and later, and then fail to bootstrap when it
didn't get the answers it wanted. Fixes bug 4013; bugfix on 0.2.3.2-alpha.
The fix here is to revert to using normal descriptors if any of our
bridges are known to not support microdescs. This is not ideal, a) because
we'll start downloading a microdesc consensus as soon as we get a bridge
descriptor, and that will waste time if we later get a bridge descriptor
that tells us we don't like microdescriptors; and b) by changing our mind
we're leaking to our other bridges that we have an old-version bridge.
The alternate fix would have been to change
we_use_microdescriptors_for_circuits() to ask if *any* of our bridges
can support microdescriptors, and then change the directory logic that
picks a bridge to only select from those that do. For people living in
the future, where 0.2.2.x is obsolete, there won't be a difference.
Note that in either of these potential fixes, we have risk of oscillation
if our one funny-looking bridges goes away / comes back.
This option seems to be supported all the way back to at least 10.4, so
enabling it for OS X in general should be fine. If not, someone will
yell.
With no libs statically linked, that's a 3% win in binary size, with
just libevent linked statically, this gives us an advantage of 5% in
terms of binary size, and with libevent and openssl statically linked,
we gain over 18% or over 500KB.
Implements ticket 2915.
These were found by looking for tor_snprintf() instances that were
followed closely by tor_strdup(), though I probably converted some
other snprintfs as well.
(To ensure correctness, in every case, make sure that the temporary
variable is deleted, renamed, or lowered in scope, so we can't have
any bugs related to accidentally relying on the no-longer-filled
variable.)
To solve bug 4779, we want to avoid OpenSSL 1.0.0's counter mode.
But Fedora (and maybe others) lie about the actual OpenSSL version,
so we can't trust the header to tell us if it's safe.
Instead, let's do a run-time test to see whether it's safe, and if
not, use our built-in version.
fermenthor contributed a pretty essential fixup to this patch. Thanks!
When we have an effective bandwidthrate configured so that we cannot
exceed our bandwidth limit in one accounting interval, don't disable
advertising the dirport. Implements ticket 2434.
Fixes bug 4413; bugfix on xxxx.
Hostname components cannot be larger than 63 characters.
This simple check makes certain randlen cannot overflow rand_bytes_len.
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).
Previously we required 1.0.0, but there was a bug in the 1.0.0 counter
mode. Found by Pascal. Fixes bug 4779.
A more elegant solution would be good here if somebody has time to code
one.
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.
