| Commit message (Collapse) | Author | Age |
|\ |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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().
|
| | |
| | |
| | |
| | |
| | |
| | | |
fixes 12114; bug not in any release.
Improves fix for 12028
|
| | |
| | |
| | |
| | | |
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
|
|\ \ \ \
| |/ / /
|/| | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
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
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This prevents a crash when rotating logs with dirreq-stats enabled
fixes 12035; bugfix on 0.2.5.1-alpha.
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
Fix for 12041; bugfix on 0.2.5.1-alpha.
|
| | | | |
|
|\ \ \ \ |
|
| | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When we converted the horrible set of options that previously
controlled "use ORPort or DirPort? Anonymously or Non-anonymouly?" to
a single 'indirection' argument, we missed
directory_post_to_dirservers.
The problematic code was introduced in 5cbeb6080, which went into
0.2.4.3-alpha. This is a fix for bug 11469.
|
| |\ \ \ |
|
| |\ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Conflicts:
src/or/microdesc.c
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The 0.2.5.x warning is the one that might help us track this down; the
warnings in stable are just annoying users over and over and over.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
When running with User set, we frequently try to look up our
information in the user database (e.g., /etc/passwd). The seccomp2
sandbox setup doesn't let us open /etc/passwd, and probably
shouldn't.
To fix this, we have a pair of wrappers for getpwnam and getpwuid.
When a real call to getpwnam or getpwuid fails, they fall back to a
cached value, if the uid/gid matches.
(Granting access to /etc/passwd isn't possible with the way we
handle opening files through the sandbox. It's not desirable either.)
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
We'll use these to deal with being unable to access the user DB
after we install the sandbox, to fix bug 11946.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
On OpenBSD 5.4, time_t is a 32-bit integer. These instances contain
implicit treatment of long and time_t as comparable types, so explicitly
cast to time_t.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
while testing
|
|\ \ \ \ \ \ |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Possible fix for bug 11648.
|
|\ \ \ \ \ \ \ |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
This may let us know if we're hitting 7164 because of an
hte_hash-corruption situation proposed by "cypherpunks" in bug
11737.
|
|\ \ \ \ \ \ \ \
| |_|/ / / / / /
|/| | | | | | | |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
This is an attempt to diagnose 8387.
|
| | | | | | | | |
|