| Commit message (Collapse) | Author | Age |
|
|
|
|
|
| |
This was causing dirauths to emit flag weight validation warns if there
was a sufficiently large amount of badexit bandwidth to make a difference in
flag weight results.
|
|
|
|
| |
This can happen in various cases of network failure.
|
|
|
|
| |
Should silence two path bias Bug messages seen on relays at startup.
|
| |
|
|
|
|
| |
Note this does not solve bug 7799, it is only to help us diagnose it.
|
| |
|
|
|
|
|
|
|
|
|
| |
It seems that some versions of clang that would prefer the
-Wswitch-enum compiler flag to warn about switch statements with
missing enum values, even if those switch statements have a
default.
Fixes bug 8598; bugfix on 0.2.4.10-alpha.
|
|
|
|
| |
It could just be due to small clock jumps, after all.
|
|
|
|
| |
This should eliminate potential regressions caused by #7341.
|
| |
|
| |
|
|
|
|
| |
Found by formorer; fix on 42fb61d172b172, not in any released Tor.
|
|
|
|
| |
Found by coverity; this is CID 992692.
|
|
|
|
|
|
| |
This caused an assertion failure when pruning guards.
Fixes bug #8553; bug not in any released Tor.
|
|\ |
|
| |
| |
| |
| | |
Fixes bug 8475; bugfix on 0.2.0.7-alpha.
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
This adds a new option to fix bug 8508 which broke chutney
networks. The bug was introduced by 317d16de.
|
|\ \
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/or/circuitbuild.c
src/or/config.c
|
| | |
| | |
| | |
| | |
| | |
| | | |
This is for bug 6304.
Add a changes file too
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
Instead, drop the cell.
Fixes another case of bug 7350; bugfix on 0.2.4.4-alpha
|
|\ \ \ |
|
| | | |
| | | |
| | | |
| | | | |
This should help us track down #7164 at last.
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Conflicts:
doc/tor.1.txt
src/or/circuitbuild.c
src/or/config.c
src/or/or.h
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Mike believes that raising the default to 2 months with no way to lower
it may create horrible load-balancing issues.
|
| | | | | |
|
| | |_|/
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fixes 8240.
(Don't actually increase the default guard lifetime. It seems likely to
break too many things if done precipitiously.)
|
|\ \ \ \ |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Without this patch, there's no way to know what went wrong when we
fail to parse a torrc line entirely (that is, we can't turn it into
a K,V pair.) This patch introduces a new function that yields an
error message on failure, so we can at least tell the user what to
look for in their nonfunctional torrc.
(Actually, it's the same function as before with a new name:
parse_config_line_from_str is now a wrapper macro that the unit
tests use.)
Fixes bug 7950; fix on 0.2.0.16-alpha (58de695f9062576f) which first
introduced the possibility of a torrc value not parsing correctly.
|
|\ \ \ \ \ |
|
| | |_|/ /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
It was previously --Test in the help output and --test-commandline in
the getopt call. The man page already had --test.
(Originally by David, who resolved the tie in favor of "--test"; I
chose --test-commandline" instead so that nothing that depended
on it could break. -Nick)
|
|\ \ \ \ \ |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
There are two ways to use sysconf to ask about the number of
CPUs. When we're on a VM, we would sometimes get it wrong by asking
for the number of total CPUs (say, 64) when we should have been asking
for the number of CPUs online (say, 1 or 2).
Fix for bug 8002.
|
|\ \ \ \ \ \ |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This time, I'm checking whether our calculated offset matches our
real offset, in each case, as we go along. I don't think this is
the bug, but it can't hurt to check.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Possible partial fix, or diagnosis tool, for bug 8031.
|
| | |_|_|/ /
| |/| | | |
| | | | | |
| | | | | | |
This is part of an attempt to mitigate 8031.
|
|\ \ \ \ \ \ |
|
| | | | | | | |
|
| | |_|/ / /
| |/| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Also, don't call the exit node 'reject *' unless our decision to pick
that node was based on a non-summarized version of that node's exit
policy.
rransom and arma came up with the ideas for this fix.
Fix for 7582; the summary-related part is a bugfix on 0.2.3.2-alpha.
|
|\ \ \ \ \ \ |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The new name is circuit_mark_all_dirty_circs_as_unusable.
This resolves an XXX024
|
| | |_|_|/ /
| |/| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
In a number of places, we decrement timestamp_dirty by
MaxCircuitDirtiness in order to mark a stream as "unusable for any
new connections.
This pattern sucks for a few reasons:
* It is nonobvious.
* It is error-prone: decrementing 0 can be a bad choice indeed.
* It really wants to have a function.
It can also introduce bugs if the system time jumps backwards, or if
MaxCircuitDirtiness is increased.
So in this patch, I add an unusable_for_new_conns flag to
origin_circuit_t, make it get checked everywhere it should (I looked
for things that tested timestamp_dirty), and add a new function to
frob it.
For now, the new function does still frob timestamp_dirty (after
checking for underflow and whatnot), in case I missed any cases that
should be checking unusable_for_new_conns.
Fixes bug 6174. We first used this pattern in 516ef41ac1fd26f338c,
which I think was in 0.0.2pre26 (but it could have been 0.0.2pre27).
|
|\ \ \ \ \ \ |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This should have been 2 bytes all along, since version numbers can
be 16 bits long. This isn't a live bug, since the call to
is_or_protocol_version_known in channel_tls_process_versions_cell
will reject any version number not in the range 1..4. Still, let's
fix this before we accidentally start supporting version 256.
Reported pseudonymously. Fixes bug 8062; bugfix on 0.2.0.10-alpha --
specifically, on commit 6fcda529, where during development I
increased the width of a version to 16 bits without changing the
type of link_proto.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Patch from 'cypherpunks'. Fixes bug #7947. Bugfix on 0.0.7.1.
|
|\ \ \ \ \ \ \ |
|