We were triggering a CLOCK_SKEW controller status event whenever
we connect via the v2 connection protocol to any relay that has
a wrong clock. Instead, we should only inform the controller when
it's a trusted authority that claims our clock is wrong. Bugfix
on 0.2.0.20-rc; starts to fix bug 1074. Reported by SwissTorExit.

Once we had called log_free_all(), anything that tried to log a
message (like a failed tor_assert()) would fail like this:

   1. The logging call eventually invokes the _log() function.
   2. _log() calls tor_mutex_lock(log_mutex).
   3. tor_mutex_lock(m) calls tor_assert(m).
   4. Since we freed the log_mutex, tor_assert() fails, and tries to
      log its failure.
   5. GOTO 1.

Now we allocate the mutex statically, and never destroy it on
shutdown.

Bugfix on 0.2.0.16-alpha, which introduced the log mutex.

This bug was found by Matt Edman.

The more verbose logs that were added in ee58153b also include a string
that might not have been initialized. This can lead to segfaults, e.g.,
when setting up private Tor networks. Initialize this string with NULL.

Send circuit or stream sendme cells when our window has decreased
by 100 cells, not when it has decreased by 101 cells. Bug uncovered
by Karsten when testing the "reduce circuit window" performance
patch. Bugfix on the 54th commit on Tor -- from July 2002,
before the release of Tor 0.0.0. This is the new winner of the
oldest-bug prize.

* debian-merge:
  New upstream version
  bump to 0.2.1.19
  document my new relay-early behavior
  Changing MaxAdvertisedBW may not need a republish
  Write fingerprint to file and log without spaces
  Don't leak memory if we get too many create cells
  three hacks to workaround bug 1038

* commit 'tor-0.2.1.19':
  bump to 0.2.1.19
  document my new relay-early behavior
  Changing MaxAdvertisedBW may not need a republish
  Write fingerprint to file and log without spaces
  Don't leak memory if we get too many create cells
  three hacks to workaround bug 1038

also bring the release notes up to date

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

Relays no longer publish a new server descriptor if they change
their MaxAdvertisedBandwidth config option but it doesn't end up
changing their advertised bandwidth numbers. Bugfix on 0.2.0.28-rc;
fixes bug 1026. Patch from Sebastian.

Now it will look like the fingerprints in our bridges documentation,
and confuse fewer users.

Specifically, every time we get a create cell but we have so many already
queued that we refuse it.

Bugfix on 0.2.0.19-alpha; fixes bug 1034. Reported by BarkerJr.

The problem is that clients and hidden services are receiving
relay_early cells, and they tear down the circuit.

Hack #1 is for rendezvous points to rewrite relay_early cells to
relay cells. That way there are never any incoming relay_early cells.

Hack #2 is for clients and hidden services to never send a relay_early
cell on an established rendezvous circuit. That works around rendezvous
points that haven't upgraded yet.

Hack #3 is for clients and hidden services to not tear down the circuit
when they receive an inbound relay_early cell. We already refuse extend
cells at clients.

* debian-merge:
  New upstream version
  bump to 0.2.1.18
  put in the full 0.2.1 release notes
  add a changelog entry for the upcoming 0.2.1.18
  make phobos's lines start with tabs again
  added LIBS=-lrt to Makefile.am for static libevent in the tor rpms.
  forward-port the 0.2.0.35 release notes
  add blurbs for recent release candidates
  Bump version to 0.2.1.17-rc-dev

* commit 'tor-0.2.1.18':
  bump to 0.2.1.18
  put in the full 0.2.1 release notes
  add a changelog entry for the upcoming 0.2.1.18
  make phobos's lines start with tabs again
  added LIBS=-lrt to Makefile.am for static libevent in the tor rpms.
  forward-port the 0.2.0.35 release notes
  add blurbs for recent release candidates
  Bump version to 0.2.1.17-rc-dev

in case Make on openirix128 can't handle it otherwise