now's your chance to destabilize it

Conflicts:

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

Apparently this is not as obvious as I thought.

Conflicts:
	src/or/config.c
	src/or/test.c

From http://archives.seul.org/tor/relays/Mar-2010/msg00006.html :

   As I understand it, the bug should show up on relays that don't set
   Address to an IP address (so they need to resolve their Address
   line or their hostname to guess their IP address), and their
   hostname or Address line fails to resolve -- at that point they'll
   pick a random 4 bytes out of memory and call that their address. At
   the same time, relays that *do* successfully resolve their address
   will ignore the result, and only come up with a useful address if
   their interface address happens to be a public IP address.

Also, differentiate the two log messages.

I still feel like we should investigate this case. It seems odd.

Also break the build if that switch isn't used and asciidoc isn't
available.

We don't need sed for our string manipulation, so let's get rid of
it. Suggested by weasel.

Otherwise, the build process breaks when one of the .1.txt gets
a new mtime. Suggested by weasel.

Conflicts:
	src/common/test.h
	src/or/test.c

When the bandwidth-weights branch added the "directory-footer"
token, and began parsing the directory footer at the first
occurrence of "directory-footer", it made it possible to fool the
parsing algorithm into accepting unsigned data at the end of a
consensus or vote.  This patch fixes that bug by treating the footer
as starting with the first "directory-footer" or the first
"directory-signature", whichever comes first.

Conflicts:
	ChangeLog
	src/or/routerparse.c

Treat strings returned from signed_descriptor_get_body_impl() as not
NUL-terminated. Since the length of the strings is available, this is
not a big problem.

Discovered by rieo.

Don't allow anything but directory-signature tokens in a consensus after
the first directory-signature token.  Fixes bug in bandwidth-weights branch.
Found by "outofwords."

Another dereference-then-NULL-check sequence. No reports of this bug
triggered in the wild. Fixes bugreport 1256.

Thanks to ekir for discovering and reporting this bug.

Fix a dereference-then-NULL-check sequence. This bug wasn't triggered
in the wild, but we should fix it anyways in case it ever happens.
Also make sure users get a note about this being a bug when they
see it in their log.

Thanks to ekir for discovering and reporting this bug.

We used to only zero the first ptrsize bytes of the cipher. Since
cipher is large enough, we didn't zero too many bytes. Discovered
and fixed by ekir. Fixes bug 1254.

This means that "if (E<G) {abc} else if (E>=G) {def}" can be replaced with
"if (E<G) {abc} else {def}"

Doing the second test explicitly made my mingw gcc nervous that we might
never be initializing casename.

For my 64-bit Linux system running with GCC 4.4.3-fc12-whatever, you
can't do 'printf("%lld", (int64_t)x);' Instead you need to tell the
compiler 'printf("%lld", (long long int)x);' or else it doesn't
believe the types match.  This is why we added U64_PRINTF_ARG; it
looks like we needed an I64_PRINTF_ARG too.

Conflicts:
	ChangeLog