David Fifield [Wed, 13 Mar 2013 07:43:21 +0000 (00:43 -0700)]
Use option name --test-commandline in tor-fw-helper.
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)
Nick Mathewson [Mon, 11 Mar 2013 20:29:06 +0000 (16:29 -0400)]
Look at the right variable when warning about signed size_t.
In 81d69f4c2d8a451 (0.2.21-alpha) we added a compile-time check for
a (totally broken) signed size_t. In 0e597471af (not yet released)
I switched to a better configure-time check, which stored its output
in a different variable. I didn't change the code which looked at
the output, however.
This bug is not in any released version of Tor, and would not affect
anybody with a working Tor.
Nick Mathewson [Mon, 11 Mar 2013 18:52:56 +0000 (14:52 -0400)]
Another possible diagnostic for 8031.
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.
Nick Mathewson [Mon, 11 Mar 2013 16:34:14 +0000 (12:34 -0400)]
Increase link_proto field to 2 bytes
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.
Nick Mathewson [Mon, 11 Mar 2013 16:29:28 +0000 (12:29 -0400)]
Fix a framing bug when reading versions from a versions cell.
Our ++ should have been += 2. This means that we'd accept version
numbers even when they started at an odd position.
This bug should be harmless in practice for so long as every version
number we allow begins with a 0 byte, but if we ever have a version
number starting with 1, 2, 3, or 4, there will be trouble here.
Fix for bug 8059, reported pseudonymously. Bugfix on 0.2.0.10-alpha
-- specifically, commit 6fcda529, where during development I
increased the width of a version to 16 bits without changing the
loop step.
Nick Mathewson [Wed, 28 Nov 2012 16:09:37 +0000 (11:09 -0500)]
Add a DisableV2DirectoryInfo_ option to 404 all v2 ns requests
I have no idea whether b0rken clients will DoS the network if the v2
authorities all turn this on or not. It's experimental. See #6783 for
a description of how to test it more or less safely, and please be
careful!
Nick Mathewson [Sun, 10 Mar 2013 12:32:58 +0000 (08:32 -0400)]
Fix 8447: use %u to format circid_t.
Now that circid_t is 4 bytes long, the default integer promotions will
leave it alone when sizeof(int) == 4, which will leave us formatting an
unsigned as an int. That's technically undefined behavior.
Nick Mathewson [Thu, 28 Feb 2013 00:38:32 +0000 (19:38 -0500)]
Remove some lingering tsocks cruft.
Now the manpages no longer refer to tsocks or tsocks.conf, and we no
longer have or ship a tor-tsocks.conf. The only remaining instances
of "tsocks" in our repository are old ChangeLog and ReleaseNotes
entries, and the torify script saying that it doesn't support tsocks.
Nick Mathewson [Tue, 19 Feb 2013 23:29:17 +0000 (18:29 -0500)]
Stop frobbing timestamp_dirty as our sole means to mark circuits unusable
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).
Nick Mathewson [Tue, 19 Feb 2013 22:32:15 +0000 (17:32 -0500)]
Make a parse_config_line_from_str variant that gives error messages
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.
Nick Mathewson [Tue, 19 Feb 2013 15:39:27 +0000 (10:39 -0500)]
Refactor storing of measured_bw versus Unmeasured=1.
This patch moves the measured_bw field and the has_measured_bw field
into vote_routerstatus_t, since only votes have 'Measured=XX' set on
their weight line.
I also added a new bw_is_unmeasured flag to routerstatus_t to
represent the Unmeasured=1 flag on a w line. Previously, I was using
has_measured_bw for this, which was quite incorrect: has_measured_bw
means that the measured_bw field is set, and it's probably a mistake
to have it serve double duty as meaning that 'baandwidth' represents a
measured value.
While making this change,I also found a harmless but stupid bug in
dirserv_read_measured_bandwidths: It assumes that it's getting a
smartlist of routerstatus_t, when really it's getting a smartlist of
vote_routerstatus_t. C's struct layout rules mean that we could never
actually get an error because of that, but it's still quite incorrect.
I fixed that, and in the process needed to add two more sorting and
searching helpers.
Finally, I made the Unmeasured=1 flag get parsed. We don't use it for
anything yet, but someday we might.
This isn't complete yet -- the new 2286 unit test doesn't build.
projects / thirdparty / tor.git / log
