| Commit message (Collapse) | Author | Age |
|---|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/or/channel.c
src/or/circuitlist.c
src/or/connection.c
Conflicts involved removal of next_circ_id and addition of
unusable-circid tracking.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The point of the "idle timeout" for connections is to kill the
connection a while after it has no more circuits. But using "last
added a non-padding cell" as a proxy for that is wrong, since if the
last circuit is closed from the other side of the connection, we
will not have sent anything on that connection since well before the
last circuit closed.
This is part of fixing 6799.
When applied to 0.2.5, it is also a fix for 12023.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Instead of killing an or_connection_t that has had no circuits for
the last 3 minutes, give every or_connection_t a randomized timeout,
so that an observer can't so easily infer from the connection close
time the time at which its last circuit closed.
Also, increase the base timeout for canonical connections from 3
minutes to 15 minutes.
Fix for ticket 6799.
|
| | | |
|
| |\ \ |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The old cache had problems:
* It needed to be manually preloaded. (It didn't remember any
address you didn't tell it to remember)
* It was AF_INET only.
* It looked at its cache even if the sandbox wasn't turned on.
* It couldn't remember errors.
* It had some memory management problems. (You can't use memcpy
to copy an addrinfo safely; it has pointers in.)
This patch fixes those issues, and moves to a hash table.
Fixes bug 11970; bugfix on 0.2.5.1-alpha.
|
| |\ \ \ |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Found while investigating 8093, but probably not the cause of it,
since this bug would result in us sending too few SENDMEs, not in us
receiving SENDMEs unexpectedly.
Bugfix on the fix for 7889, which has appeared in 0.2.4.10-alpha, but
not yet in any released 0.2.3.x version.
|
| |\ \ \ \ |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
When we find a stranded one-hop circuit, log whether it is dirty,
log information about any streams on it, and log information about
connections they might be linked to.
|
| |\ \ \ \ \
| |/ / / /
|/| | | | |
|
| | |\ \ \ \ |
|
| | | | | | | |
|
| | |\ \ \ \ \
| | |/ / / /
| |/| | | | |
|
| | | | | | | |
|
| |\ \ \ \ \ \ |
|
| | |/ / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This function is supposed to construct a list of all the ciphers in
the "v2 link protocol cipher list" that are supported by Tor's
openssl. It does this by invoking ssl23_get_cipher_by_char on each
two-byte ciphersuite ID to see which ones give a match. But when
ssl23_get_cipher_by_char cannot find a match for a two-byte SSL3/TLS
ciphersuite ID, it checks to see whether it has a match for a
three-byte SSL2 ciphersuite ID. This was causing a read off the end
of the 'cipherid' array.
This was probably harmless in practice, but we shouldn't be having
any uninitialized reads.
(Using ssl23_get_cipher_by_char in this way is a kludge, but then
again the entire existence of the v2 link protocol is kind of a
kludge. Once Tor 0.2.2 clients are all gone, we can drop this code
entirely.)
Found by starlight. Fix on 0.2.4.8-alpha. Fixes bug 12227.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Fixes bug in b0c1c700114aa8d4dfc180d85870c5bbe15fcacb; bug
12229. Bugfix not in any released Tor. Patch from "alphawolf".
|
| |\ \ \ \ \ \ |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
tor_memeq has started to show up on profiles, and this is one of the
most frequent callers of that function, appearing as it does on every
cell handled for entry or exit.
59f9097d5c3dc010847c359888d31757d1c97904 introduced tor_memneq here;
it went into Tor 0.2.1.31. Fixes part of 12169.
|
| |\ \ \ \ \ \ \ |
|
| | |/ / / / / / |
|
| |\ \ \ \ \ \ \ |
|
| | | |/ / / / /
| |/| | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This code mis-handled the case where a circuit got the same circuit
ID in both directions. I found three instances of it in the
codebase, by grepping for [pn]_circ_id.
Because of the issue in command_process_relay_cell(), this would
have made roughly one circuit in a million completely nonfunctional.
Fixes bug 12195.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Patch from Roger; changes file by me.
Fixes 10405; bugfix on 0.2.3.9-alpha, where DisableNetwork was
introduced.
|
| |\ \ \ \ \ \ \
| |_|/ / / / /
|/| | | | | | |
|
| | |/ / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
On some profiles of Andrea's from #11332, I found that a great deal
of time can still be attributed to functions called from
update_router_have_minimum_dir_info(). This is making our
digestmap, tor_memeq, and siphash functions take a much bigger
portion of runtime than they really should.
If we're calling update_router_have_minimum_dir_info() too often,
that's because we're calling router_dir_info_changed() too often.
And it looks like most of the callers of router_dir_info_changed()
are coming as tail-calls from router_set_status() as invoked by
channel_do_open_actions().
But we don't need to call router_dir_info_changed() so much! (I'm
not quite sure we need to call it from here at all, but...) Surely
we don't need to call it from router_set_status when the router's
status has not actually changed.
This patch makes us call router_dir_info_changed() from
router_set_status only when we are changing the router's status.
Fix for bug 12170. This is leftover from our fix back in 273ee3e81
in 0.1.2.1-alpha, where we started caching the value of
update_router_have_minimum_dir_info().
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
(See discussion on #9553)
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
fixes bug 12139; bugfix on 0.2.5.1-alpha
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Fix for 12115; bugfix on 0.2.5.1-alpha
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
fixes 12114; bug not in any release.
Improves fix for 12028
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
(This is how I found out I was trying to test with a kernel too old
for seccomp. I think.)
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This is a minimal set of changes for compilation; I need a more
recent kernel to test this stuff.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Bugfix on cfd0ee514c279bc6c7b; bug not in any released version of tor
|
| |\ \ \ \ \ \ |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Without this fix, when running with bridges, we would try fetching
directory info far too early, and have up to a 60 second delay if we
started with bridge descriptors available.
Fixes bug 11965. Fix on 0.2.3.6-alpha, arma thinks.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
fixes part of 12064
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
There was too much code duplication in doing it the old way, and I
nearly made a copy-and-paste error in the last commit.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
fixes part of 12064
|
| | |_|_|_|/ /
|/| | | | |
| | | | | |
| | | | | | |
Fix for 12064 part 1
|
| |\ \ \ \ \ \
| |/ / / / /
|/| | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
These are needed under some circumstances if we are running with
expensive-hardening and sandbox at the same time.
fixes 11477, bugfix on 0.2.5.4-alpha (where we introduced
expensive-hardening)
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Fixes bug 12032; bugfix on 0.2.5.1-alpha
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Also, don't tolerate changing DirPortFrontPage.
Fixes bug 12028; bugfix on 0.2.5.1-alpha.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
None of the things we might exec() can possibly run under the
sanbox, so rather than crash later, we have to refuse to accept the
configuration nice and early.
The longer-term solution is to have an exec() helper, but wow is
that risky.
fixes 12043; bugfix on 0.2.5.1-alpha
|