mfwitten authored 15 years ago and Nick Mathewson committed 15 years ago

The following commit:

    commit e56747f9
    Author: Nick Mathewson <nickm@torproject.org>
    Date:   Tue Dec 15 14:32:55 2009 -0500

        Refactor a bit so that it is safe to include math.h, and mostly not needed.

introduced this line:

    tor_resolve_LDADD = -lm ../common/libor.a @TOR_LIB_WS32@

which caused the build to fail, because only ../common/libor.a
(via the embedded ../common/util.o via ../common/util.c)
referenced libm's `lround' and `log' symbols, so that the
linker (GNU ld) didn't bother to import those symbols before
reading ../common/libor.a, thus leaving those symbols undefined.

The solution was to swap the order, producing the line:

    tor_resolve_LDADD = ../common/libor.a -lm @TOR_LIB_WS32@

Signed-off-by: Michael Witten <mfwitten@gmail.com>

Conflicts:
	ChangeLog
	configure.in
	contrib/tor-mingw.nsi.in
	src/win32/orconfig.h

if we try to read it to publish stats and it's not there,
that means there are no stats to publish.

reported by swisstorexit.

we never used them, and maybe it's a bad idea to publish them

somebody should add man page entries.

Mark them this way in add_trusted_dir_server

They weren't in sync with reality nor manpage, and only useful to a human
who could simply have checked the manpage.

...to let us
rate-limit client connections as they enter the network. It's
controlled in the consensus so we can turn it on and off for
experiments. It's starting out off. Based on proposal 163.

it's wrong, but that's our problem not its problem

Specifically, there are two cases: a) are we willing to start a new
circuit at a node not in your ExitNodes config option, and b) are we
willing to make use of a circuit that's already established but has an
unsuitable exit.

Now we discard all your circuits when you set ExitNodes, so the only
way you could end up with an exit circuit that ends at an unsuitable
place is if we explicitly ran out of exit nodes, StrictNodes was 0,
and we built this circuit to solve a stream that needs solving.

Fixes bug in dc322931, which would ignore the just-built circuit because
it has an unsuitable exit.

If ExcludeNodes or ExcludeExitNodes changes on a config reload,
mark and discard all our origin circuits.

Before it would prepend your requested entrynodes to your list of guard
nodes, but feel free to use others after that. Now it chooses only
from your EntryNodes if any of those are available, and only falls back
to others if a) they're all down and b) StrictNodes is not set.

Also, now we refresh your entry guards from EntryNode at each consensus
fetch (rather than just at startup and then they slowly rot as the
network changes).

The goal here is to make users less likely to set StrictNodes, since
it's doing closer to what they expect it should be doing.

This is step one of handling ExcludedNodes better. This first
step is just to make EntryNodes and ExitNodes do what they did
before.