| Age | Commit message (Collapse) | Author |
|---|
|
This code changes it so that we don't remove bridges immediately when
we start re-parsing our configuration. Instead, we mark them all, and
remove all the marked ones after re-parsing our bridge lines. As we
add a bridge, we see if it's already in the list. If so, we just
unmark it.
This new behavior will lose the property we used to have that bridges
were in bridge_list in the same order in which they appeared in the
torrc. I took a quick look through the code, and I'm pretty sure we
didn't actually depend on that anywhere.
This is for bug 3019; it's a fix on 0.2.0.3-alpha.
|
|
We need to make sure that the worst thing that a weird consensus param
can do to us is to break our Tor (and only if the other Tors are
reliably broken in the same way) so that the majority of directory
authorities can't pull any attacks that are worse than the DoS that
they can trigger by simply shutting down.
One of these worse things was the cbtnummodes parameter, which could
lead to heap corruption on some systems if the value was sufficiently
large.
This commit fixes this particular issue and also introduces sanity
checking for all consensus parameters.
|
|
|
|
Conflicts:
src/common/memarea.c
src/or/or.h
src/or/rendclient.c
|
|
|
|
|
|
|
|
Use 4/3 of this timeout value for 4 hop circuits, and use half of it for
canabalized circuits.
|
|
We used to mark all our known bridges up when they're all down and we
get a new socks request. Now do that when we've set EntryNodes too.
|
|
|
|
Also remove some #if 0'd code from the unit tests for buffers. The
code was killed in e6794e58081af773073c266e23fe3ab2ebecdb7e (5 years
ago), and is now broken anyways.
|
|
Remove the msg parameter to pass an error message out. This
wasn't needed and made it harder to detect a memory leak.
|
|
|
|
|
