We used to do this as a workaround for older Tors, but now it's never
the correct thing to do (especially since anything that didn't
understand RELAY_EARLY is now deprecated hard).

Dan Rosenberg authored 13 years ago and Sebastian Hahn committed 13 years ago

Fixes bug 4410.

Robert Ransom authored 13 years ago and Sebastian Hahn committed 13 years ago

Fix suggested by Nick Mathewson.

Nick Mathewson authored 13 years ago and Roger Dingledine committed 13 years ago

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.

Roger Dingledine authored 13 years ago and Sebastian Hahn committed 13 years ago

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.

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

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.

Conflicts:

	src/or/config.c

Robert Ransom authored 14 years ago and Sebastian Hahn committed 13 years ago

Fixes bug 2572.

When we added support for separate client tls certs on bridges in
a2bb0bfd we forgot to correctly initialize this when changing
from relay to bridge or vice versa while Tor is running. Fix that
by always initializing keys when the state changes.

Fixes bug 2433.

Conflicts:

	src/or/config.c

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

We use a hash of the identity key to seed a prng to tell when an
accounting period should end.  But thanks to the bug998 changes,
clients no longer have server-identity keys to use as a long-term seed
in accounting calculations.  In any case, their identity keys (as used
in TLS) were never never fixed.  So we can just set the wakeup time
from a random seed instead there.  Still open is whether everybody
should be random.

This patch fixes bug 2235, which was introduced in 0.2.2.18-alpha.

Diagnosed with help from boboper on irc.

In a2bb0bfd we started using a separate client identity key. When we are
in "public server mode" (that means not a bridge) we will use the same
key. Reusing the key without doing the proper refcounting leads to a
segfault on cleanup during shutdown. Fix that.

Also introduce an assert that triggers if our refcount falls below 0.
That should never happen.

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

We now require that:
  - Only actual servers should ever call get_server_identity_key
  - If you're being a client or bridge, the client and server keys should
    differ.
  - If you're being a public relay, the client and server keys
    should be the same.

Robert Ransom authored 14 years ago and Sebastian Hahn committed 13 years ago

Fixes a bug described in ticket #988.

Conflicts:

	src/or/main.c
	src/or/router.c

Robert Ransom authored 14 years ago and Sebastian Hahn committed 13 years ago

Fixes bug #988.

Conflicts:

	src/or/main.c
	src/or/router.c

Robert Ransom authored 14 years ago and Sebastian Hahn committed 13 years ago

* Make tor_tls_context_new internal to tortls.c, and return the new
  tor_tls_context_t from it.

* Add a public tor_tls_context_init wrapper function to replace it.

Conflicts:

	src/or/main.c
	src/or/router.c

Nick Mathewson authored 14 years ago and Roger Dingledine committed 13 years ago

From the code:
   zlib 1.2.4 and 1.2.5 do some "clever" things with macros.  Instead of
   saying "(defined(FOO) ? FOO : 0)" they like to say "FOO-0", on the theory
   that nobody will care if the compile outputs a no-such-identifier warning.

   Sorry, but we like -Werror over here, so I guess we need to define these.
   I hope that zlib 1.2.6 doesn't break these too.

Possible fix for bug 1526.

Nobody but Tor uses certs on the wire with 2 hour lifetimes,
and it makes us stand out. Resolves ticket 4014.

Using strncpy meant that if listenaddress were ever >=
sizeof(sockaddr_un.sun_path), we would fail to nul-terminate
sun_path.  This isn't a big deal: we never read sun_path, and the
kernel is smart enough to reject the sockaddr_un if it isn't
nul-terminated.  Nonetheless, it's a dumb failure mode.  Instead, we
should reject addresses that don't fit in sockaddr_un.sun_path.

Coverity found this; it's CID 428.  Bugfix on 0.2.0.3-alpha.

When we rejected a descriptor for not being the one we wanted, we
were letting the parsed descriptor go out of scope.

Found by Coverity; CID # 30.

Bugfix on 0.2.1.26.

(No changes file yet, since this is not in any 0.2.1.x release.)

I'm not one to insist on C's miserly stack limits, but allocating a
256K array on the stack is too much even for me.

Bugfix on 0.2.1.7-alpha.  Found by coverity.  Fixes CID # 450.