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.

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.

Linus Nordberg authored 12 years ago and Nick Mathewson committed 12 years ago

Closes #6423.

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.

Also promote log messages to notice and rate-limit them.

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.

Apparently, we weren't actually detecting wildcardedness when parsing
them: whoops!

bug 6244.  Bugfix on 0.2.3.9-alpha

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.

Spotted by asn

Found by George, who gets a cookie.

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.

Conflicts:
	src/or/routerlist.c

I don't personally agree that this is likely to be easy to exploit,
and some initial experimention I've done suggests that cache-miss
times are just plain too fast to get useful info out of when they're
mixed up with the rest of Tor's timing noise.  Nevertheless, I'm
leaving Robert's initial changelog entry in the git history so that he
can be the voice of reason if I'm wrong. :)

Robert Ransom authored 12 years ago and Nick Mathewson committed 12 years ago

Tor's and OpenSSL's current design guarantee that there are other leaks,
but this one is likely to be more easily exploitable, and is easy to fix.

Fix for 6530; fix on 0.2.2.6-alpha.

I can't currently find a bug here, but there are a couple of
near-misses.  Addresses ticket 6514; reported pseudonymously on
IRC.

Fixes 6480; fix on 0.2.0.1-alpha; based on pseudonymous patch.

Ondrej Mikle authored 12 years ago and Nick Mathewson committed 12 years ago

Workaround for building EL5 RPMs by specifying rpmbuild-md5. Updated old note about using static libevent when building RPMs.

Ondrej Mikle authored 12 years ago and Nick Mathewson committed 12 years ago

Cleanup of RPM build process - no more .git in tarball, use automake's dist-gzip to create the tarball.

Signed-off-by: Ondrej Mikle <ondrej.mikle@gmail.com>