UseBridges 1 now means "connect only to bridges; if you know no
bridges, don't make connections."  UseBridges auto means "Use bridges
if they are known, and we have no EntryNodes set, and we aren't a
server."  UseBridges 0 means "don't use bridges."

options->DirPort is 0 in the unit tests, so
router_get_advertised_dir_port() would return 0 so we wouldn't pick a
dirport. This isn't what we want for the unit tests. Fixes bug
introduced in 95ac3ea5.

I hope these will never be useful, but having them and not needing them is
better than needing them and not having them.

Fixes bug #3309.

Previously, Tor would dereference a NULL pointer and crash if
lookup_last_hid_serv_request were called before the first call to
directory_clean_last_hid_serv_requests.  As far as I can tell, that's
currently impossible, but I want that undocumented invariant to go away
in case I^Wwe break it someday.

Gisle authored 13 years ago and Nick Mathewson committed 13 years ago

An elusive compile-error (MingW-gcc v4.50 on Win_XP); a missing
comma (!) and a typo ('err_msg' at line 277 changed to 'errmsg').
Aso changed the format for 'err_code' at line 293 into a "%ld" to suppress
a warning. How did this go unnoticed for ~1 month? Btw. This is my 1st ever
'git commit', so it better work.

When we introduced NEED_KEY_1024 in routerparse.c back in
0.2.0.1-alpha, I forgot to add a *8 when logging the length of a
bad-length key.

Bugfix for 3318 on 0.2.0.1-alpha.

If you had configured a bridge but then switched to a different bridge
via the controller, you would still be willing to use the old one.

The patch for 3228 made us try to run init_keys() before we had loaded
our state file, resulting in an assert inside init_keys. We had moved
it too early in the function.

Now it's later in the function, but still above the accounting calls.

Sebastian Hahn authored 13 years ago and Nick Mathewson committed 13 years ago

This simple implementation has a few issues, but it should do for
0.2.2.x. We will want to revisit this later and make it smarter.

Conflicts:
	src/or/circuitbuild.c

The comment fixes are trivial.  The defensive programming trick is to
tolerate receiving NULL inputs on the describe functions. That should
never actually happen, but it seems like the likeliest mistake for us
to make in the future.

Previously we did this nearer to the end (in the old_options &&
transition_affects_workers() block).  But other stuff cares about
keys being consistent with options... particularly anything which
tries to access a key, which can die in assert_identity_keys_ok().

Fixes bug 3228; bugfix on 0.2.2.18-alpha.

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

Fixes another part of bug 1297.

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

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.)

The previous attempt was incomplete: it told us not to publish a
descriptor, but didn't stop us from generating one.  Now we treat an
absent OR port the same as not knowing our address.  (This means
that when we _do_ get an OR port, we need to mark the descriptor
dirty.)

More attempt to fix bug3216.

Nick Mathewson authored 13 years ago and Sebastian Hahn committed 13 years ago

This situation can happen easily if you set 'ORPort auto' and
'AccountingMax'.  Doing so means that when you have no ORPort, you
won't be able to set an ORPort in a descriptor, so instead you would
just generate lots of invalid descriptors, freaking out all the time.

Possible fix for 3216; fix on 0.2.2.26-beta.

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

On win64, sockets are of type UINT_PTR; on win32 they're u_int;
elsewhere they're int.  The correct windows way to check a socket for
being set is to compare it with INVALID_SOCKET; elsewhere you see if
it is negative.

On Libevent 2, all callbacks take sockets as evutil_socket_t; we've
been passing them int.

This patch should fix compilation and correctness when built for
64-bit windows.  Fixes bug 3270.