| Commit message (Collapse) | Author | Age |
|---|
| |\ |
|
| | | |
|
| | |\ |
|
| | | | |
|
| | |\ \
| | |/
| |/| |
|
| | | | |
|
| |\ \ \ |
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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().
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I've copied the entries from changes/, labeled the ones that also
appeared in 0.2.4.22, sorted them lightly with a python script
(added to maint), and combined sections with the same name.
I didn't combine sections without a description (e.g. "Minor
bugfixes:"), since we'll probably add a description to those.
|
| | | |
| | |
| | |
| | | |
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
|
| | | | |
| | | |
| | | |
| | | | |
Our documentation had the name of this directory wrong.
|
| |\ \ \ \
| |/ / /
|/| | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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
|