See #4771 for rationale.
Note that this patch does not take suggested changes in #4470 into
account and keeps treating AuthDirHasIPv6Connectivity as an
AUTOBOOL. Thus, bug fixes for that are included here as well.
This is a fix on master, unreleased as of now.
Also, make node_get_prim_orport() indicate in its return value whether
a valid OR port was copied or not.
Maybe we should make it legal to pass ap_out==NULL?
Also, do this only for clients, explicitly.
Also, give the flag a value every time we set consensus. We used to
touch it only when ClientPreferIPv6ORPort was set, which was wrong.
extend_info_from_node() used to use the primary OR port (i.e. IPv4)
unless the node had routerinfo. Now that we have IPv6 addresses in
microdescs we may want to use them.
Note that this patch changes using r->cache_info.identity_digest into
using node->identity. I count on these being well synchronised, or
things would break in other ways. Right?
Add ClientUseIPv6 and ClientPreferIPv6ORPort configuration options.
Use "preferred OR port" for all entry nodes, not only for bridges.
Mark bridges with "prefer IPv6 OR port" if an IPv6 address is
configured in Bridge line and ClientPreferIPv6ORPort is set.
Mark relays with "prefer IPv6 OR port" if an IPv6 address is found in
descriptor and ClientPreferIPv6ORPort is set.
Filter "preferred OR port" through the ClientUseIPv6 config option. We
might want to move this test to where actual connection is being set
up once we have a fall back mechanism in place.
Have only non-servers pick an IPv6 address for the first hop: We
don't want relays to connect over IPv6 yet. (IPv6 has never been used
for second or third hops.)
Implements ticket 5535.
Generate and store all supported microdescriptor formats. Generate
votes with one "m" line for each format. Only "m" lines with version
info matching chosen consensus method will be voted upon.
An optimisation would be to combine "m" lines with identical hashes,
i.e. instead of "m 1,2,3 H1" and "m 4,5 H1", say "m 1,2,3,4,5 H1".
Define new new consensus method 14 adding "a" lines to vote and
consensus documents.
From proposal 186:
As with other data in the vote derived from the descriptor, the
consensus will include whichever set of "a" lines are given by the
most authorities who voted for the descriptor digest that will be
used for the router.
This patch implements this.
Allow one-hop directory fetching circuits the full "circuit build timeout"
period, rather than just half of it, before failing them and marking
the relay down. This fix should help reduce cases where clients declare
relays (or worse, bridges) unreachable because the TLS handshake takes
a few seconds to complete.
Fixes bug 6743 (one piece of bug 3443); bugfix on 0.2.2.2-alpha, where
we changed the timeout from a static 30 seconds.
We've had over two months to fix them, and didn't. Now we need
0.2.3.x stable. Yes, it would be cool to get this working in
0.2.3.x, but not at the expense of delaying every other feature that
_does_ work in 0.2.3.x. We can do a real fix in 0.2.4.
This is important, since otherwise an attacker can use timing info
to probe the internal network.
Also, add an option (ExtendAllowPrivateAddresses) so that
TestingTorNetwork won't break.
Fix for bug 6710; bugfix on all released versions of Tor.
Move extend_info_from_router() from circuitbuild.c to router.c and
make it static.
Add get_configured_bridge_by_orports_digest() and have
get_configured_bridge_by_routerinfo() and
node_is_a_configured_bridge() use it. We now consider all OR ports of
a bridge when looking for it.
Move node_get_*_orport to nodelist.c.
Fix a cut'n'paste error in header of nodelist.h.
Add node_assert_ok().
Add router_get_all_orports(). It's duplicating code from
node_get_all_orports(). Worth fixing at the cost of complicating the
API slightly?
There was some code in the "err:" block that would always log a
warning, reporting an "unknown error" if we hadn't set err_msg. But
there were also plenty of "goto err" blocks that did their own
logging, and never set err_msg at all. Now we should only log when
we have an error message to log.
This fixes bug 6638, from no released Tor version.
Failure to do this would lead to double-free cases and similar,
especially when the exit's DNS was broken. See bug 6472 for full
details; this is a fix for 6472.
Anonymous patch from "cypherpunks" on trac.
Long ago, before we had cell queues, it was necessary to maybe call
connection_handle_write() from connectino_write_to_buf_impl() on OR
connections, so that we wouldn't get into a loop of reading infinite
amounts of data and queueing it all on an outbuf before bothering to
write any data.
If that doesn't sounds like what our code does now, you're right:
right now, we won't stick more than OR_CONN_HIGHWATER bytes of cells
on an outbuf, and we won't suck more than CELL_QUEUE_HIGHWATER_SIZE
cells off any edge connection. So, there's no more call for that
code.
Removing this code will simplify our data flow, and that should be
something we can all get behind.
Apparently, (void)writev is not enough to suppress the "you are
ignoring the return value!" warnings on Linux. Instead, remove the
whole warning/error logic when compiling openbsd_malloc for Tor: we
can't use it.
This is done to avoid spurious warns. Additional log lines are also
added to try to track down the codepaths where we are somehow overcounting
success counts.
The warning fixes are:
- Only define issetugid if it's missing.
- Explicitly ignore the return value of writev.
- Explicitly cast the retval of readlink() to int.
The 64-bit problems are related to just storing a size_t in an int. Not cool! Use a size_t instead.
Fix for bug 6379. Bugfix on 0.2.0.20-rc, which introduced openbsd-malloc.
This patch extracts the inner part of config_register_addressmaps --
the part that knows about detecting wildcard addresses addresses --
and makes it into a new function. The new function is deliberately
not moved or reindented, so that the diff is smaller.
I need this to fix bug 6244.
Extend cells aren't allowed to have a stream_id, but we were only
blocking them when they had a stream_id that corresponded to a
connection. As far as I can tell, this change is harmless: it will
make some kinds of broken clients not work any more, but afaik nobody
actually make a client that was broken in that way.
Found while hunting for other places where we made the same mistake
as in 6271.
Bugfix on d7f50337c1 back from May 2003, which introduced
telescoping circuit construction into 0.0.2pre8.
Thanks to the changes we started making with SocksPort and friends
in 0.2.3.3-alpha, any of our code that did "if (options->Sockport)"
became wrong, since "SocksPort 0" would make that test true whereas
using the default SocksPort value would make it false. (We didn't
actually do "if (options->SockPort)" but we did have tests for
TransPort. When we moved DirPort, ORPort, and ControlPort over to
the same system in 0.2.3.9-alpha, the problem got worse, since our
code is littered with checks for DirPort and ORPort as booleans.
This code renames the current linelist-based FooPort options to
FooPort_lines, and adds new FooPort_set options which get set at
parse-and-validate time on the or_options_t. FooPort_set is true
iff we will actually try to open a listener of the given type. (I
renamed the FooPort options rather than leave them alone so that
every previous user of a FooPort would need to get inspected, and so
that any new code that forgetfully uses FooPort will need fail to
compile.)
Fix for bug 6507.
With this patch, I dump the old kludge of using magic negative
numbers to indicate unknown bandwidths. I also compute each node's
weighted bandwidth exactly once, rather than computing it once in
a loop to compute the total weighted bandwidth and a second time in
a loop to find which one we picked.
Previously, we had incremented rand_bw so that when we later tested
"tmp >= rand_bw", we wouldn't have an off-by-one error. But instead,
it makes more sense to leave rand_bw alone and test "tmp > rand_bw".
Note that this is still safe. To take the example from the bug1203
writeup: Suppose that we have 3 nodes with bandwidth 1. So the
bandwidth array is { 1, 1, 1 }, and the total bandwidth is 3. We
choose rand_bw == 0, 1, or 2. With the first iteration of the loop,
tmp is now 1; with the second, tmp is 2; with the third, tmp is 3.
Now that our check is tmp > rand_bw, we will set i in the first
iteration of the loop iff rand_bw == 0; in the second iteration of
the loop iff rand_bw == 1, and in the third iff rand_bw == 2.
That's what we want.
Incidentally, this change makes the bug 6538 fix more ironclad: once
rand_bw is set to UINT64_MAX, tmp > rand_bw is obviously false
regardless of the value of tmp.
The old approach, because of its "tmp >= rand_bw &&
!i_has_been_chosen" check, would run through the second part of the
loop slightly slower than the first part. Now, we remove
i_has_been_chosen, and instead set rand_bw = UINT64_MAX, so that
every instance of the loop will do exactly the same amount of work
regardless of the initial value of rand_bw.
Fix for bug 6538.
This should make our preferred solution to #6538 easier to
implement, avoid a bunch of potential nastiness with excessive
int-vs-double math, and generally make the code there a little less
scary.
"But wait!" you say. "Is it really safe to do this? Won't the
results come out differently?"
Yes, but not much. We now round every weighted bandwidth to the
nearest byte before computing on it. This will make every node that
had a fractional part of its weighted bandwidth before either
slighty more likely or slightly less likely. Further, the rand_bw
value was only ever set with integer precision, so it can't
accurately sample routers with tiny fractional bandwidth values
anyway. Finally, doing repeated double-vs-uint64 comparisons is
just plain sad; it will involve an implicit cast to double, which is
never a fun thing.
This gives us a few benefits:
1) make -j clean all
this will start working, as it should. It currently doesn't.
2) increased parallel build
recursive make will max out at number of files in a directory,
non-recursive make doesn't have such a limitation
3) Removal of duplicate information in make files,
less error prone
I've also slightly updated how we call AM_INIT_AUTOMAKE, as the way
that was used was not only deprecated but will be *removed* in the next
major automake release (1.13).... so probably best that we can continue
to bulid tor without requiring old automake.
(see http://www.gnu.org/software/automake/manual/html_node/Public-Macros.html )
For more reasons why, see resources such as:
http://miller.emu.id.au/pmiller/books/rmch/
In 0.2.3.18-rc, we started warning on this case while building a
list of missing microdescriptor digests. That turned out to spam
the logs; instead let's warn at parse time.
Partial fix for bug 6404.
The spec requires that every router in a microdesc consensus have an
m line; we weren't obeying that spec.
This creates a new consensus method (13) to allow voting to continue
to work right. Partial fix for bug 6404; fix on 0.2.2.6-alpha.
