| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Also fix a bug where if the guard we choose first doesn't answer, we
would try the second guard, but once we connected to the second guard
we would abandon it and retry the first one, slowing down bootstrapping.
The fix in both cases is to treat all our initially chosen guards as
acceptable to use.
Fixes bug 9946.
|
|
|
|
|
|
|
|
|
|
|
|
Fix format_helper_exit_status to allow full HEX_ERRNO_SIZE answers,
*and* increase the buffer length again.
|
|
|
|
|
|
This reverts the torrc.sample.in changes from commit
66a04a6ac334775dc396025e0c15fa49eca138a7.
We're going to not make this change in 0.2.4, since changing
torrc.sample.in makes all the debian users do some pointless
busywork. see tor-dev discusion of 9 Oct 2013.
|
|
Explicitly include bridges, and note that we archive and publish all
descriptors.
(We are not yet publishing ContactInfo lines contained in bridge
descriptors, but maybe we'll want to do that soon, so let's err on the
side of caution here.)
Related to #9854.
|
|
Patch from "hantwister" on trac. Fixes bug #9904; bugfix on
0.2.3.11-alpha.
|
|
According to the manpage, bridges use P256 for conformity and relays
use P224 for speed. But skruffy points out that we've gotten it
backwards in the code.
In this patch, we make the default P256 for everybody.
Fixes bug 9780; bugfix on 0.2.4.8-alpha.
|
|
|
|
|
|
|
|
Fix for 9927.
|
|
This is probably not an exploitable bug, since you would need to have
errno be a large negative value in the unix pluggable-transport launcher
case. Still, best avoided.
Fixes bug 9928; bugfix on 0.2.3.18-rc.
|
|
By calling circuit_n_chan_done() unconditionally on close, we were
closing pending connections that might not have been pending quite for
the connection we were closing. Fix for bug 9880.
Thanks to skruffy for finding this and explaining it patiently until
we understood.
|
|
To fix #6033, we disabled TLS 1.1 and 1.2. Eventually, OpenSSL fixed
the bug behind #6033.
I've considered alternate implementations that do more testing to see
if there's secretly an OpenSSL 1.0.1c or something that secretly has a
backport of the OpenSSL 1.0.1e fix, and decided against it on the
grounds of complexity.
|
|
|
|
|
|
This avoids skew warnings as authorities test reachability.
Fix 9798; fix not on any released Tor.
|
|
this was causing directory authorities to send a time of 0 on all
connections they generated themselves, which means everybody reachability
test caused a time skew warning in the log for that relay.
(i didn't just revert, because the changes file has been modified by
other later commits.)
|
|
Implements part of proposal 222. We can do this safely, since
REND_CACHE_MAX_SKEW is 24 hours.
|
|
This isn't actually much of an issue, since only relays send
AUTHENTICATE cells, but while we're removing timestamps, we might as
well do this too.
Part of proposal 222. I didn't take the approach in the proposal of
using a time-based HMAC, since that was a bad-prng-mitigation hack
from SSL3, and in real life, if you don't have a good RNG, you're
hopeless as a Tor server.
|
|
For now, round down to the nearest 10 minutes. Later, eliminate entirely by
setting a consensus parameter.
(This rounding is safe because, in 0.2.2, where the timestamp mattered,
REND_REPLAY_TIME_INTERVAL was a nice generous 60 minutes.)
|
|
Implements part of proposal 222.
|
|
We were freeing these on exit, but when we added the dl_status_map
field to them in fddb814f, we forgot to arrange for it to be freed.
I've moved the cert_list_free() code into its own function, and added
an appropriate dsmap_free() call.
Fixes bug 9644; bugfix on 0.2.4.13-alpha.
|
|
The problem was that the server_identity_key_is_set() function could
return true under conditions where we don't really have an identity
key -- specifically, where we used to have one, but we stopped being a
server.
This is a fix for 6979; bugfix on 0.2.2.18-alpha where we added that
assertion to get_server_identity_key().
|
|
|
|
|
|
|
|
we skip onionskins that came from non-relays, so we're less likely to
run into privacy troubles.
starts to implement ticket 9658.
|
|
Now we explicitly check for overflow.
This approach seemed smarter than a cascade of "change int to unsigned
int and hope nothing breaks right before the release".
Nick, feel free to fix in a better way, maybe in master.
|
|
with commit c6f1668d we let it grow arbitrarily large.
it can still overflow, but the damage is very small now.
|
|
|
|
Now we consider the TAP cells we'll process while draining the NTor
queue, and vice versa.
|
|
|
|
that way tap won't starve entirely, but we'll still handle ntor requests
quicker.
|
|
|
|
|
|
|
|
Now we prioritize ntor create cells over tap create cells.
Starts to address ticket 9574.
|
|
Conflicts:
src/or/circuitbuild.c
|
|
This would make us do testing circuits "even when cbt is disabled by
consensus, or when we're a directory authority, or when we've failed
to write cbt history to our state file lately." (Roger's words.)
This is a fix for 9671 and an improvement in our fix for 5049.
The original misbehavior was in 0.2.2.14-alpha; the incomplete
fix was in 0.2.3.17-beta.
|
|
|
|
Fix for bug 9400, spotted by coverity. Bug introduced in revision 2cb4f7a4
(subversion revision r389).
|
