This replaces the old FallbackConsensus notion, and should provide a
way -- assuming we pick reasonable nodes! -- to give clients
suggestions of placs to go to get their first consensus.
This is the simplest possible workaround: make it safe to call
circuit_cell_queue_clear() on a non-attached circuit, and make it
safe-but-a-LD_BUG-warning to call update_circuit_on_cmux() on a
non-attached circuit.
LocalWords: unstage src Untracked
Apparently some compilers like to eliminate memset() operations on
data that's about to go out-of-scope. I've gone with the safest
possible replacement, which might be a bit slow. I don't think this
is critical path in any way that will affect performance, but if it
is, we can work on that in 0.2.4.
Fixes bug 7352.
Instead of warning about low ports that are advertised, we should have
been warning about low ports that we're listening on. Bug 7285, fix
on 0.2.3.9-alpha.
That's not where I'd want to put a $, but apparently the other
foo/id/<identity> things allow it, as does an arguably valid
interpretation of control-spec.txt. So let's be consistent.
Fix for a piece of bug 7059.
This is part of what's needed to build without warnings on mingw64:
it was warning about the cast from void* to long that happened in
the places we were using test_{n,}eq on pointers.
The alternative here would have been to broaden tt_int_op to accept
a long long or an intptr_t, but that's less correct (since pointers
aren't integers), and would hurt the portability of tinytest a
little.
Fixes part of 7260.
We still want to build on compilers w/o c99 support, such as
(notoriously, shamefully) MSVC.
So I'm commenting out the designated initializers in
circuitmux_ewma.c. The alternative would have been to use some kind
of macros to use designated initializers only when they're
supported, but that's error-prone, and can lead to code having
different meanings under different compilers.
Bug 7286; fix on 0.2.4.4-alpha; spotted by Gisle Vanem.
If we completed the handshake for the v2 link protocol but wound up
negotiating the wong protocol version, we'd become so confused about
what part of the handshake we were in that we'd promptly die with an
assertion.
This is a fix for CVE-2012-2250; it's a bugfix on 0.2.3.6-alpha.
All servers running that version or later should really upgrade.
Bug and fix from "some guy from France." I tweaked his code slightly
to make it log the IP of the offending node, and to forward-port it to
0.2.4.
If we completed the handshake for the v2 link protocol but wound up
negotiating the wong protocol version, we'd become so confused about
what part of the handshake we were in that we'd promptly die with an
assertion.
This is a fix for CVE-2012-2250; it's a bugfix on 0.2.3.6-alpha.
All servers running that version or later should really upgrade.
Bug and fix from "some guy from France." I tweaked his code slightly
to make it log the IP of the offending node.
Clients now consider the ClientRejectInternalAddresses config option
when using a microdescriptor consensus stanza to decide whether
an exit relay would allow exiting to an internal address. Fixes
bug 7190; bugfix on 0.2.3.1-alpha.
Our implementation of parse_short_policy was screwed up: it would
ignore the last character of every short policy. Obviously, that's
broken.
This patch fixes the busted behavior, and adds a bunch of unit tests
to make sure the rest of that function is okay.
Fixes bug 7192; fix on 0.2.3.1-alpha.
Conflicts:
src/or/circuitbuild.c
There was a huge-looking conflict in circuitbuild.c, but the only
change that had been made to circuitbuild.c since I forked off the
split_circuitbuild branch was 17442560c4. So I took the
split_circuitbuild version of the conflicting part, and manually
re-applied the change from 17442560c44e8093f9a..
OpenSSL 1.0.0 added an implementation of TLS session tickets, a
"feature" that let session resumption occur without server-side state
by giving clients an encrypted "ticket" that the client could present
later to get the session going again with the same keys as before.
OpenSSL was giving the keys to decrypt these tickets the lifetime of
the SSL contexts, which would have been terrible for PFS if we had
long-lived SSL contexts. Fortunately, we don't. Still, it's pretty
bad. We should also drop these, since our use of the extension stands
out with our non-use of session cacheing.
Found by nextgens. Bugfix on all versions of Tor when built with
openssl 1.0.0 or later. Fixes bug 7139.
Failure to do so left us open to a remotely triggerable assertion
failure. Fixes CVE-2012-2249; bugfix on 0.2.3.6-alpha. Reported by
"some guy from France".
This patch is a forward-port to 0.2.4, to work with the new channel
logic.
Failure to do so left us open to a remotely triggerable assertion
failure. Fixes CVE-2012-2249; bugfix on 0.2.3.6-alpha. Reported by
"some guy from France".
Our convention is that we use the changelog to note release-to-release
changes; we don't need to add changelog entries for bugs that didn't
appear in any released version of Tor. (By convention, we sometimes
say "this bug does not appear in any released version of Tor" or words
to that effect in the commit message so that when Roger goes to make
sure the changelog is right, he knows not to expect a changelog entry
for that part.)
There are as many divergent implementations of sys/queue.h as there
are operating systems shipping it, it would seem. They have some code
in common, but have drifted apart, and have added other stuff named
differently. So I'm taking a relatively sane one, and hoping for the
best.
I'm taking OpenBSD's in particular because of the lack of external
dependencies, the presence of a CIRCLEQ (we could use one of those in
places), and the liberal licensing terms.
I'm naming the file tor_queue.h, since historically we've run into
trouble having headers with the same names as system headers (log.h,
for example.)
The rationale for treating these files differently is that we should
be checking upstream for changes as applicable, and merging changes
upstream as warranted.
Conflicts:
src/or/circuitbuild.c
The conflict was trivial, since no line of code actually changed in
both branches: There was a fmt_addr() that turned into fmt_addrport()
in bug7011, and a "if (!n_conn)" that turned into "if (!n_chan)" in
master.
They're typically redundant with the "Your computer is too slow"
messages. Fixes bug 7038; bugfix on 0.2.2.16-alpha.
(In retrospect, we should have fixed this bug back in ticket 1042.)
We used to never return an IPv6 address unless ClientUseIPv6 was
set. We should allow clients running with bridges use IPv6 OR ports
even without setting ClientUseIPv6. Configuring an IPv6 address in a
Bridge line should imply that.
Fixes th second part of #6757.
Look at the address family of the preferred OR port rather than the
node.ipv6_preferred flag since the logic has changed with new
ClientUseIPv6 config option.
Fixes ticket 6884.
Right-shifting negative values has implementation-defined behavior.
On all the platforms we work on right now, the behavior is to
sign-extend the input. That isn't what we wanted in
auth_type_val = (descriptor_cookie_tmp[16] >> 4) + 1;
Fix for 6861; bugfix on 0.2.1.5-alpha; reported pseudonymously.
The broken behavior didn't actually hurt anything, I think, since the
only way to get sign-extension to happen would be to have the top bit
of descriptor_cookie_tmp[16] set, which would make the value of
descriptor_cookie_tmp[16] >> 4 somewhere between 0b11111111 and
0b11111000 (that is, between -1 and -8). So auth_type_val would be
between -7 and 0. And the immediate next line does:
if (auth_type_val < 1 || auth_type_val > 2) {
So the incorrectly computed auth_type_val would be rejected as
invalid, just as a correctly computed auth_type_val would be.
Still, this stuff shouldn't sit around the codebase.
We were doing (1<<p) to generate a flag at position p, but we should
have been doing (U64_LITERAL(1)<<p).
Fixes bug 6861; bugfix on 0.2.0.3-alpha; reported pseudonymously.
We already had code on windows to fix our file sizes when we're
reading a file in text mode and its size doesn't match the size from
fstat. But that code was only enabled when _WIN32 was defined, and
Cygwin defines __CYGWIN__ instead.
Fixes bug 6844; bugfix on 0.1.2.7-alpha.
This would be undefined behavior if it happened. (It can't actually
happen as we're using round_to_power_of_2, since we would have to
be trying to allocate exabytes of data.)
While we're at it, fix the behavior of round_to_power_of_2(0),
and document the function better.
Fix for bug 6831.
Our flag voting code needs to handle unrecognized flags, so it stores
them in a 64-bit bitfield. But we never actually checked for too many
flags, so we were potentially doing stuff like U64_LITERAL(1)<<flagnum
with flagnum >= 64. That's undefined behavior.
Fix for bug 6833; bugfix on 0.2.0.1-alpha.
