| Commit message (Collapse) | Author | Age |
|
|
|
|
|
| |
bug4020
Signed-off-by: Tom Fitzhenry <tom@tom-fitzhenry.me.uk>
|
| |
|
| |
|
|
|
|
|
| |
Tor2webMode is fingerprintable by hidden services through repeated
usage of the same three guard nodes for its rend and intro points.
|
| |
|
|\ |
|
| | |
|
| |
| |
| |
| | |
Asserts were hit by Tor2Web mode.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Look at the address family of the preferred OR port rather than the
node.ipv6_preferred flag since the logic has changed with new
ClientUseIPv6 config option.
Fixes ticket 6884.
|
|\ \ |
|
| | |
| | |
| | |
| | | |
This affects both directory authorities and bridge authoritites.
|
| | | |
|
|\ \ \ |
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | | |
We were doing (1<<p) to generate a flag at position p, but we should
have been doing (U64_LITERAL(1)<<p).
Fixes bug 6861; bugfix on 0.2.0.3-alpha; reported pseudonymously.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Right-shifting negative values has implementation-defined behavior.
On all the platforms we work on right now, the behavior is to
sign-extend the input. That isn't what we wanted in
auth_type_val = (descriptor_cookie_tmp[16] >> 4) + 1;
Fix for 6861; bugfix on 0.2.1.5-alpha; reported pseudonymously.
The broken behavior didn't actually hurt anything, I think, since the
only way to get sign-extension to happen would be to have the top bit
of descriptor_cookie_tmp[16] set, which would make the value of
descriptor_cookie_tmp[16] >> 4 somewhere between 0b11111111 and
0b11111000 (that is, between -1 and -8). So auth_type_val would be
between -7 and 0. And the immediate next line does:
if (auth_type_val < 1 || auth_type_val > 2) {
So the incorrectly computed auth_type_val would be rejected as
invalid, just as a correctly computed auth_type_val would be.
Still, this stuff shouldn't sit around the codebase.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
|\ \ \ |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Our flag voting code needs to handle unrecognized flags, so it stores
them in a 64-bit bitfield. But we never actually checked for too many
flags, so we were potentially doing stuff like U64_LITERAL(1)<<flagnum
with flagnum >= 64. That's undefined behavior.
Fix for bug 6833; bugfix on 0.2.0.1-alpha.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
They don't like to have #preprocessor directives inside macro arguments.
Fixes #6842; fix on 0.2.4.2-alpha.
Found by grarpamp.
|
| | | | |
|
| | | | |
|
|/ / /
| | |
| | |
| | |
| | | |
This helps us split up one of our larger files, and sets the stage
for refactoring the configuration backend a little
|
|\| | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fixes bug 6827; bugfix on c58675ca728f12b42f65e5b8964ae695c2e0ec2d
(when the v2 HS desc parser was implemented).
Found by asn.
|
|\ \ \ |
|
| | | | |
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When I removed version_supports_begindir, I accidentally removed the
mechanism we had been using to make a directory cache self-test its
directory port. This caused bug 6815, which caused 6814 (both in
0.2.4.2-alpha).
To fix this bug, I'm replacing the "anonymized_connection" argument to
directory_initiate_command_* with an enumeration to say how indirectly
to connect to a directory server. (I don't want to reinstate the
"version_supports_begindir" argument as "begindir_ok" or anything --
these functions already take too many arguments.)
For safety, I made sure that passing 0 and 1 for 'indirection' gives
the same result as you would have gotten before -- just in case I
missed any 0s or 1s.
|
|\ \ \
| |/ /
|/| /
| |/ |
|
| |\ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This avoids a possible crash bug in flush_from_first_active_circuit.
Fixes bug 6341; bugfix on 0.2.2.7-alpha.
Bug reported and fixed by a pseudonymous user on IRC.
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
Conflicts:
configure.ac
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
The smart part of this is based on an approach and a suggestion by
rransom. The unsmart part is my own fault.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
This eliminates duplicated code, and lets us test a hairy piece of
functionality.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
With this patch, I dump the old kludge of using magic negative
numbers to indicate unknown bandwidths. I also compute each node's
weighted bandwidth exactly once, rather than computing it once in
a loop to compute the total weighted bandwidth and a second time in
a loop to find which one we picked.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Previously, we had incremented rand_bw so that when we later tested
"tmp >= rand_bw", we wouldn't have an off-by-one error. But instead,
it makes more sense to leave rand_bw alone and test "tmp > rand_bw".
Note that this is still safe. To take the example from the bug1203
writeup: Suppose that we have 3 nodes with bandwidth 1. So the
bandwidth array is { 1, 1, 1 }, and the total bandwidth is 3. We
choose rand_bw == 0, 1, or 2. With the first iteration of the loop,
tmp is now 1; with the second, tmp is 2; with the third, tmp is 3.
Now that our check is tmp > rand_bw, we will set i in the first
iteration of the loop iff rand_bw == 0; in the second iteration of
the loop iff rand_bw == 1, and in the third iff rand_bw == 2.
That's what we want.
Incidentally, this change makes the bug 6538 fix more ironclad: once
rand_bw is set to UINT64_MAX, tmp > rand_bw is obviously false
regardless of the value of tmp.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The old approach, because of its "tmp >= rand_bw &&
!i_has_been_chosen" check, would run through the second part of the
loop slightly slower than the first part. Now, we remove
i_has_been_chosen, and instead set rand_bw = UINT64_MAX, so that
every instance of the loop will do exactly the same amount of work
regardless of the initial value of rand_bw.
Fix for bug 6538.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This should make our preferred solution to #6538 easier to
implement, avoid a bunch of potential nastiness with excessive
int-vs-double math, and generally make the code there a little less
scary.
"But wait!" you say. "Is it really safe to do this? Won't the
results come out differently?"
Yes, but not much. We now round every weighted bandwidth to the
nearest byte before computing on it. This will make every node that
had a fractional part of its weighted bandwidth before either
slighty more likely or slightly less likely. Further, the rand_bw
value was only ever set with integer precision, so it can't
accurately sample routers with tiny fractional bandwidth values
anyway. Finally, doing repeated double-vs-uint64 comparisons is
just plain sad; it will involve an implicit cast to double, which is
never a fun thing.
|
|\ \ \ \
| | |/ /
| |/| | |
|
| |\ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
Conflicts:
src/test/test_util.c
|
| | | | |
| | | | |
| | | | |
| | | | | |
Fixes bug 6811.
|
|\| | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
If s_values is null in rep_hist_load_bwhist_state_section, we would
call smartlist_len() on it, and die.
Fixes bug 6801.
|
|\ \ \ \ \ |
|
| | | | | | |
|