Robert Ransom authored May 29, 2011 and Nick Mathewson committed May 30, 2011

Fixes another part of bug 1297.

Robert Ransom authored May 29, 2011 and Nick Mathewson committed May 30, 2011

Fixes part of #1297; bugfix on 48e0228f,
when circuit_expire_building was changed to assume that timestamp_dirty
was set when a circuit changed purpose to _C_REND_READY.  (It wasn't.)

We had all the code in place to handle this right... except that we
were unconditionally opening a PF_INET socket instead of looking at
sa_family.  Ow.

Fixes bug 2574; not a bugfix on any particular version, since this
never worked before.

Most instances were dead code; for those, I removed the assignments.
Some were pieces of info we don't currently plan to use, but which
we might in the future.  For those, I added an explicit cast-to-void
to indicate that we know that the thing's unused.  Finally, one was
a case where we were testing the wrong variable in a unit test.
That one I fixed.

This resolves bug 3208.

It used to mean "Force": it would tell tor-resolve to ask tor to
resolve an address even if it ended with .onion.  But when
AutomapHostsOnResolve was added, automatically refusing to resolve
.onion hosts stopped making sense.  So in 0.2.1.16-rc (commit
298dc95d), we made tor-resolve happy to resolve anything.

The -F option stayed in, though, even though it didn't do anything.
Oddly, it never got documented.

Found while fixing GCC 4.6 "set, unused variable" warnings.

Conflicts:
	src/common/Makefile.am

Sebastian Hahn authored May 21, 2011 and Roger Dingledine committed May 21, 2011

We used to regenerate our descriptor whenever we'd get a sighup. This
was caused by a bug in options_transition_affects_workers() that would
return true even if the options were exactly the same. Down the call
path we'd call init_keys(), which made us make a new descriptor which
the authorities would reject, and the node would subsequently fall out
of the consensus.

This patch fixes only the first part of this bug:
options_transition_affects_workers() behaves correctly now. The second
part still wants a fix.

tor_process_monitor_new can't currently return NULL, but if it ever can,
we want that to be an explicitly fatal error, without relying on the fact
that monitor_owning_controller_process's chain of caller will exit if it
fails.

Implements part of feature 3049.

now we have a better chance of hunting down the root cause of bug 1810.

otherwise we might reuse circuits from the previous configuration,
which could be bad depending on the user's situation

When we configure a new bridge via the controller, don't wait up to ten
seconds before trying to fetch its descriptor. This wasn't so bad when
you listed your bridges in torrc, but it's dreadful if you configure
your bridges via vidalia.

Fixes bug 2313; bugfix on 0.2.2.26-beta.