svn:r18429

svn:r18426

svn:r18425

svn:r18423

svn:r18422

svn:r18421

a directory mirror. Bugfix on 0.2.0.9-alpha; reported by lark.


svn:r18420

(but not in 0.2.1.12-alpha, sorry)


svn:r18417

svn:r18416

svn:r18413

svn:r18411

svn:r18404

we run as root.  Do not set it when run as debian-tor as Tor then always
insists on changing users which will fail.  (If we run as any other user we
don't set our debian defaults anyway.)


svn:r18397

to forgive our bridges and try again when we get an application
request. Bugfix on 0.2.0.x.


svn:r18396

svn:r18395

svn:r18394

svn:r18392

redundant, and is definitely confusing. we should take it out
in 0.2.2.x and see who squeaks.


svn:r18383

svn:r18365

Fix a possible cause of bug 915 when parsing multiple votes one of which was bad.  Bugfix on 0.2.0.8-alpha.

svn:r18354

GCC's interpretation of the C99 aliasing rules, to be charitable,
creates a dialect of C intended for a better programmers than I am
certain of my ability to be in all times.  I just spent 2 hours
tracking down a platform-hyperspecific libevent bug that turned out to
be because of this, and darned if I ever want to do *that* again.

One of Linus's recent rants will give you a picture of why GCC's
behavior here can lead to fun surprises in your binaries:
http://lwn.net/Articles/316126/

svn:r18351

merge the 'bridge relay' section into the 'main relay'
section, so people stop getting confused about whether they
should fill out both sections (they shouldn't).


svn:r18348

svn:r18341

svn:r18335

one to slip if something is going to


svn:r18334

svn:r18327

svn:r18325

svn:r18316

svn:r18307

This resolves bug 526, wherein we would crash if the following
events occurred in this order:
  A: We're an OR, and one of our nameservers goes down.
  B: We launch a probe to it to see if it's up again. (We do this hourly
     in steady-state.)
  C: Before the probe finishes, we reconfigure our nameservers,
     usually because we got a SIGHUP and the resolve.conf file changed.
  D: The probe reply comes back, or times out. (There is a five-second
     window for this, after B has happens).

IOW, if one of our nameservers is down and our nameserver
configuration has changed, there were 5 seconds per hour where HUPing
the server was unsafe.

Bugfix on 0.1.2.1-alpha.  Too obscure to backport.

svn:r18306

This fixes the last known case of bug 891, which could happen if two
hosts, A and B, disagree about how long a circuit has been open,
because of clock drift of some kind.  Host A would then mark the
connection as is_bad_for_new_circs when it got too old and open a new
connection.  In between when B receives a NETINFO cell on the new
conn, and when B receives a conn cell on the new circuit, the new
circuit will seem worse to B than the old one, and so B will mark it
as is_bad_for_new_circs in the second or third loop of
connection_or_group_set_badness().

Bugfix on 0.1.1.13-alpha.  Bug found by rovv.

Not a backport candidate: the bug is too obscure and the fix too tricky.

svn:r18303

svn:r18302

svn:r18301

svn:r18299

Actually send the extra_headers content in write_http_response_header_impl.  This make X-Descriptor-Now-New get sent.  Bugfix on 0.2.0.10-alpha.  Spotted by "multiplication".

svn:r18297

svn:r18288

svn:r18287

svn:r18286

svn:r18283

a new event. what a mess.


svn:r18277