These shouldn't really matter, but it's nice to be leak-free.

Fixes CID 980650; bugfix on 0.2.4.10-alpha.

This test was accounting for about 2/3 of our unit tests' runtime,
even on systems with a fast curve25519.  No test should take so long.

It returns the method by which we decided our public IP address
(explicitly configured, resolved from explicit hostname, guessed from
interfaces, learned by gethostname).

Now we can provide more helpful log messages when a relay guesses its IP
address incorrectly (e.g. due to unexpected lines in /etc/hosts). Resolves
ticket 2267.

While we're at it, stop sending a stray "(null)" in some cases for the
server status "EXTERNAL_ADDRESS" controller event. Resolves bug 8200.

To avoid surprises, good coding practice suggests parenthesizing every
macro definition -- or at the very least, all those involving an
expression.

This check isn't necessary (see comment on #7801), but it took at
least two smart people a little while to see why it wasn't necessary,
so let's have it in to make the code more readable.

We need a weak RNG in a couple of places where the strong RNG is
both needless and too slow.  We had been using the weak RNG from our
platform's libc implementation, but that was problematic (because
many platforms have exceptionally horrible weak RNGs -- like, ones
that only return values between 0 and SHORT_MAX) and because we were
using it in a way that was wrong for LCG-based weak RNGs.  (We were
counting on the low bits of the LCG output to be as random as the
high ones, which isn't true.)

This patch adds a separate type for a weak RNG, adds an LCG
implementation for it, and uses that exclusively where we had been
using the platform weak RNG.

Conflicts:
	src/or/connection.c

Fixes bug 7727; fix on 0.2.4.10-alpha.

This beats our old implementation, which wouldn't work when cross-compiling

Conflicts:
	src/common/util.c

Mike Perry authored 12 years ago and Nick Mathewson committed 12 years ago

I think we want both sets of messages to appear independently to help us know
what needs tuning.

Right now, all our curve25519 backends ignore the high bit of the
public key. But possibly, others could treat the high bit of the
public key as encoding out-of-bounds values, or as something to be
preserved. This could be used to distinguish clients with different
backends, at the cost of killing a circuit.

As a workaround, let's just clear the high bit of each public key
indiscriminately before we use it. Fix for bug 8121, reported by
rransom. Bugfix on 0.2.4.8-alpha.