Nick Mathewson [Tue, 7 Mar 2017 18:45:32 +0000 (13:45 -0500)]
String-based API for consensus diffs.
Also, add very strict split/join functions, and totally forbid
nonempty files that end with somethig besides a newline. This
change is necessary to ensure that diff/apply are actually reliable
inverse operations.
Daniel Martí [Tue, 7 Mar 2017 14:58:30 +0000 (09:58 -0500)]
Consensus diff backend from Daniel Martí GSOC project.
(This commit was extracted by nickm based on the final outcome of
the project, taking only the changes in the files touched by this
commit from the consdiff_rebased branch. The directory-system
changes are going to get worked on separately.)
teor [Thu, 2 Mar 2017 04:14:45 +0000 (15:14 +1100)]
Remove delay in hidden service introduction point checks
Make hidden services with 8 to 10 introduction points check for failed
circuits immediately after startup. Previously, they would wait for 5
minutes before performing their first checks.
Fixes bug 21594; bugfix on commit 190aac0eab9 in Tor 0.2.3.9-alpha.
Reported by alecmuffett.
Alexander Færøy [Mon, 27 Feb 2017 14:57:08 +0000 (15:57 +0100)]
Reset `buf` after each succesful test to avoid artifacts.
This patch resets `buf` in test_util_fgets_eagain() after each succesful
ivocation to avoid stray artifacts left in the buffer by erroneous
tor_fgets() calls.
Alexander Færøy [Mon, 27 Feb 2017 14:37:31 +0000 (15:37 +0100)]
Add compatibility function for fgets(3).
This patch adds the `tor_fgets()` function to our compatibility layer.
`tor_fgets()` adds an additional check for whether the error-bit have
been enabled for the given file stream, if that is the case and `errno`
is set to `EAGAIN` we make sure that we always return NULL.
Unfortunately `fgets(3)` behaves differently on different versions of
the C library.
Nick Mathewson [Wed, 1 Mar 2017 20:02:16 +0000 (15:02 -0500)]
Restore correct behavior of 0.3.0.4-rc with bridges+ipv6-min
In that chutney test, the bridge client is configured to connect to
the same bridge at 127.0.0.1:5003 _and_ at [::1]:5003, with no
change in transports.
That meant, I think, that the descriptor is only assigned to the
first bridge when it arrives, and never the second.
Improve descriptor checks in the new guard algorithm.
- Make sure we check at least two guards for descriptor before making
circuits. We typically use the first primary guard for circuits, but
it can also happen that we use the second primary guard (e.g. if we
pick our first primary guard as an exit), so we should make sure we
have descriptors for both of them.
- Remove BUG() from the guard_has_descriptor() check since we now know
that this can happen in rare but legitimate situations as well, and we
should just move to the next guard in that case.
Nick Mathewson [Tue, 28 Feb 2017 15:37:25 +0000 (10:37 -0500)]
Merge branch 'maint-0.2.7-redux' into maint-0.2.8
This is an "ours" merge to avoid taking a version bump, and to
avoid replaying the post-0.2.7.6 history of "maint-0.2.7-redux" onto maint-0.2.8, which already included the relevant changes.
Nick Mathewson [Tue, 14 Feb 2017 17:21:31 +0000 (12:21 -0500)]
Change approach to preventing duplicate guards.
Previously I'd made a bad assumption in the implementation of
prop271 in 0.3.0.1-alpha: I'd assumed that there couldn't be two
guards with the same identity. That's true for non-bridges, but in
the bridge case, we allow two bridges to have the same ID if they
have different addr:port combinations -- in order to have the same
bridge ID running multiple PTs.
Fortunately, this assumption wasn't deeply ingrained: we stop
enforcing the "one guard per ID" rule in the bridge case, and
instead enforce "one guard per <id,addr,port>".
We also needed to tweak our implementation of
get_bridge_info_for_guard, since it made the same incorrect
assumption.
Nick Mathewson [Mon, 13 Feb 2017 14:10:11 +0000 (09:10 -0500)]
Code to disable memory sentinels for fuzzing
This feature makes it possible to turn off memory sentinels (like
those used for safety in buffers.c and memarea.c) when fuzzing, so
that we can catch bugs that they would otherwise prevent.
Nick Mathewson [Mon, 13 Feb 2017 20:37:41 +0000 (15:37 -0500)]
Revise the logic for picking the start time for link certs
Since 0.2.4.11-alpha (in 0196647970a91d) we've tried to randomize
the start time to up to some time in the past. But unfortunately we
allowed the start time to be in the future as well, which isn't
really legit.
The new behavior lets the start time be be up to
MAX(cert_lifetime-2days, 0) in the past, but never in the future.
projects / thirdparty / tor.git / log
