Commit Graph

28207 Commits

Author SHA1 Message Date
Isis Lovecruft
ad369313f8
protover: Change protover_all_supported() to return only unsupported.
Previously, if "Link=1-5" was supported, and you asked protover_all_supported()
(or protover::all_supported() in Rust) if it supported "Link=3-999", the C
version would return "Link=3-999" and the Rust would return "Link=6-999".  These
both behave the same now, i.e. both return "Link=6-999".
2018-04-02 19:59:12 +00:00
Isis Lovecruft
cd28b4c7f5
rust: Refactor protover::compute_for_old_tor().
During code review and discussion with Chelsea Komlo, she pointed out
that protover::compute_for_old_tor() was a public function whose
return type was `&'static CStr`.  We both agree that C-like parts of
APIs should:

1. not be exposed publicly (to other Rust crates),
2. only be called in the appropriate FFI code,
3. not expose types which are meant for FFI code (e.g. `*mut char`,
   `CString`, `*const c_int`, etc.) to the pure-Rust code of other
   crates.
4. FFI code (e.g. things in `ffi.rs` modules) should _never_ be called
   from pure-Rust, not even from other modules in its own crate
   (i.e. do not call `protover::ffi::*` from anywhere in
   `protover::protoset::*`, etc).

With that in mind, this commit makes the following changes:

 * CHANGE `protover::compute_for_old_tor()` to be
   visible only at the `pub(crate)` level.
 * RENAME `protover::compute_for_old_tor()` to
   `protover::compute_for_old_tor_cstr()` to reflect the last change.
 * ADD a new `protover::compute_for_old_tor()` function wrapper which
   is public and intended for other Rust code to use, which returns a
   `&str`.
2018-04-02 19:59:12 +00:00
Isis Lovecruft
fd127bfbfa
rust: Refactor Rust implementation of protover_is_supported_here().
It was changed to take borrows instead of taking ownership.

 * REFACTOR `protover::ffi::protover_is_supported_here()` to use changed method
   signature on `protover::is_supported_here()`.
2018-04-02 19:36:26 +00:00
Isis Lovecruft
32638ed4a6
rust: Refactor Rust impl of protover_compute_vote().
This includes a subtle difference in behaviour to the previous Rust
implementation, where, for each vote that we're computing over, if a single one
fails to parse, we skip it.  This now matches the current behaviour in the C
implementation.

 * REFACTOR `protover::ffi::protover_compute_vote()` to use
   new types and methods.
2018-04-02 19:36:25 +00:00
Isis Lovecruft
269053a380
rust: Refactor Rust impl of protover_list_supports_protocol_or_later().
This includes a subtle difference in behaviour, as in 4258f1e18, where we return
(matching the C impl's return behaviour) earlier than before if parsing failed,
saving us computation in parsing the versions into a
protover::protoset::ProtoSet.

 * REFACTOR `protover::ffi::protover_list_supports_protocol_or_later()` to use
   new types and methods.
2018-04-02 19:36:25 +00:00
Isis Lovecruft
63eeda89ea
rust: Refactor Rust impl of protover_list_supports_protocol().
This includes a subtle difference in behaviour, as in 4258f1e18, where we return
(matching the C impl's return behaviour) earlier than before if parsing failed,
saving us computation in parsing the versions into a
protover::protoset::ProtoSet.

 * REFACTOR `protover::ffi::protover_list_supports_protocol()` to use new types
   and methods.
2018-04-02 19:34:26 +00:00
Isis Lovecruft
c7bcca0233
rust: Refactor Rust impl of protover_all_supported().
This includes differences in behaviour to before, which should now more closely
match the C version:

 - If parsing a protover `char*` from C, and the string is not parseable, this
   function will return 1 early, which matches the C behaviour when protocols
   are unparseable.  Previously, we would parse it and its version numbers
   simultaneously, i.e. there was no fail early option, causing us to spend more
   time unnecessarily parsing versions.

 * REFACTOR `protover::ffi::protover_all_supported()` to use new types and
   methods.
2018-04-02 19:34:26 +00:00
Isis Lovecruft
493e565226
rust: Refactor protover tests with new methods; note altered behaviours.
Previously, the rust implementation of protover considered an empty string to be
a valid ProtoEntry, while the C version did not (it must have a "=" character).
Other differences include that unknown protocols must now be parsed as
`protover::UnknownProtocol`s, and hence their entries as
`protover::UnvalidatedProtoEntry`s, whereas before (nearly) all protoentries
could be parsed regardless of how erroneous they might be considered by the C
version.

My apologies for this somewhat messy and difficult to read commit, if any part
is frustrating to the reviewer, please feel free to ask me to split this into
smaller changes (possibly hard to do, since so much changed), or ask me to
comment on a specific line/change and clarify how/when the behaviours differ.

The tests here should more closely match the behaviours exhibited by the C
implementation, but I do not yet personally guarantee they match precisely.

 * REFACTOR unittests in protover::protover.
 * ADD new integration tests for previously untested behaviour.
 * FIXES part of #24031: https://bugs.torproject.org/24031.
2018-04-02 19:34:25 +00:00
Isis Lovecruft
35b86a12e6
rust: Refactor protover::is_supported_here().
This changes `protover::is_supported_here()` to be aware of new datatypes
(e.g. don't call `.0` on things which are no longer tuple structs) and also
changes the method signature to take borrows, making it faster, threadable, and
easier to read (i.e. the caller can know from reading the function signature
that the function won't mutate values passed into it).

 * CHANGE the `protover::is_supported_here()` function to take borrows.
 * REFACTOR the `protover::is_supported_here()` function to be aware of new
   datatypes.
 * FIXES part of #24031: https://bugs.torproject.org/24031
2018-04-02 19:34:25 +00:00
Isis Lovecruft
2eb1b7f2fd
rust: Add new ProtoverVote type and refactor functions to methods.
This adds a new type for votes upon `protover::ProtoEntry`s (technically, on
`protover::UnvalidatedProtoEntry`s, because the C code does not validate based
upon currently known protocols when voting, in order to maintain
future-compatibility), and converts several functions which would have operated
on this datatype into methods for ease-of-use and readability.

This also fixes a behavioural differentce to the C version of
protover_compute_vote().  The C version of protover_compute_vote() calls
expand_protocol_list() which checks if there would be too many subprotocols *or*
expanded individual version numbers, i.e. more than MAX_PROTOCOLS_TO_EXPAND, and
does this *per vote* (but only in compute_vote(), everywhere else in the C seems
to only care about the number of subprotocols, not the number of individual
versions).  We need to match its behaviour in Rust and ensure we're not allowing
more than it would to get the votes to match.

 * ADD new `protover::ProtoverVote` datatype.
 * REMOVE the `protover::compute_vote()` function and refactor it into an
   equivalent-in-behaviour albeit more memory-efficient voting algorithm based
   on the new underlying `protover::protoset::ProtoSet` datatype, as
   `ProtoverVote::compute()`.
 * REMOVE the `protover::write_vote_to_string()` function, since this
   functionality is now generated by the impl_to_string_for_proto_entry!() macro
   for both `ProtoEntry` and `UnvalidatedProtoEntry` (the latter of which is the
   correct type to return from a voting protocol instance, since the entity
   voting may not know of all protocols being voted upon or known about by other
   voting parties).
 * FIXES part of #24031: https://bugs.torproject.org/24031

rust: Fix a difference in compute_vote() behaviour to C version.
2018-04-02 19:34:24 +00:00
Isis Lovecruft
fa15ea104d
rust: Add macro for impl ToString for {Unvalidated}ProtoEntry.
This implements conversions from either a ProtoEntry or an UnvalidatedProtoEntry
into a String, for use in replacing such functions as
`protover::write_vote_to_string()`.

 * ADD macro for implementing ToString trait for ProtoEntry and
   UnvalidatedProtoEntry.
 * FIXES part of #24031: https://bugs.torproject.org/24031
2018-04-02 19:34:24 +00:00
Isis Lovecruft
3c47d31e1f
rust: Add new protover::UnvalidatedProtoEntry type.
This adds a new protover::UnvalidatedProtoEntry type, which is the
UnknownProtocol variant of a ProtoEntry, and refactors several functions which
should operate on this type into methods.

This also fixes what was previously another difference to the C implementation:
if you asked the C version of protovet_compute_vote() to compute a single vote
containing "Fribble=", it would return NULL.  However, the Rust version would
return "Fribble=" since it didn't check if the versions were empty before
constructing the string of differences.  ("Fribble=" is technically a valid
protover string.)  This is now fixed, and the Rust version in that case will,
analogous to (although safer than) C returning a NULL, return None.

 * REMOVE internal `contains_only_supported_protocols()` function.
 * REMOVE `all_supported()` function and refactor it into
   `UnvalidatedProtoEntry::all_supported()`.
 * REMOVE `parse_protocols_from_string_with_no_validation()` and
   refactor it into the more rusty implementation of
   `impl FromStr for UnvalidatedProtoEntry`.
 * REMOVE `protover_string_supports_protocol()` and refactor it into
   `UnvalidatedProtoEntry::supports_protocol()`.
 * REMOVE `protover_string_supports_protocol_or_later()` and refactor
   it into `UnvalidatedProtoEntry::supports_protocol_or_later()`.
 * FIXES part of #24031: https://bugs.torproject.org/24031

rust: Fix another C/Rust different in compute_vote().

This fixes the unittest from the prior commit by checking if the versions are
empty before adding a protocol to a vote.
2018-04-02 19:34:23 +00:00
Isis Lovecruft
54c964332b
rust: Add new protover::ProtoEntry type which uses new datatypes.
This replaces the `protover::SupportedProtocols` (why would you have a type just
for things which are supported?) with a new, more generic type,
`protover::ProtoEntry`, which utilises the new, more memory-efficient datatype
in protover::protoset.

 * REMOVE `get_supported_protocols()` and `SupportedProtocols::tor_supported()`
   (since they were never used separately) and collapse their functionality into
   a single `ProtoEntry::supported()` method.
 * REMOVE `SupportedProtocols::from_proto_entries()` and reimplement its
   functionality as the more rusty `impl FromStr for ProtoEntry`.
 * REMOVE `get_proto_and_vers()` function and refactor it into the more rusty
   `impl FromStr for ProtoEntry`.
 * FIXES part of #24031: https://bugs.torproject.org/24031
2018-04-02 19:32:36 +00:00
Isis Lovecruft
60daaa68b1
rust: Add new protover::UnknownProtocol type.
* ADD new type, protover::UnknownProtocol, so that we have greater type safety
   and our protover functionality which works with unsanitised protocol names is
   more clearly demarcated.
 * REFACTOR protover::Proto, renaming it protover::Protocol to mirror the new
   protover::UnknownProtocol type name.
 * ADD a utility conversion of `impl From<Protocol> for UnknownProtocol` so that
   we can easily with known protocols and unknown protocols simultaneously
   (e.g. doing comparisons, checking their version numbers), while not allowing
   UnknownProtocols to be accidentally used in functions which should only take
   Protocols.
 * FIXES part of #24031: https://bugs.torproject.org/24031
2018-04-02 19:27:51 +00:00
Isis Lovecruft
e6625113c9
rust: Implement more memory-efficient protover datatype.
* ADD new protover::protoset module.
 * ADD new protover::protoset::ProtoSet class for holding protover versions.
 * REMOVE protover::Versions type implementation and its method
   `from_version_string()`, and instead implement this behaviour in a more
   rust-like manner as `impl FromStr for ProtoSet`.
 * MOVE the `find_range()` utility function from protover::protover to
   protover::protoset since it's only used internally in the
   implementation of ProtoSet.
 * REMOVE the `contract_protocol_list()` function from protover::protover and
   instead refactor it (reusing nearly the entire thing, with minor superficial,
   i.e. non-behavioural, changes) into a more rusty
   `impl ToString for ProtoSet`.
 * REMOVE the `expand_version_range()` function from protover::protover and
   instead refactor it into a more rusty implementation of
   `impl Into<Vec<Version>> for ProtoSet` using the new error types in
   protover::errors.
 * FIXES part of #24031: https://bugs.torproject.org/24031.
2018-04-02 19:26:26 +00:00
Isis Lovecruft
88204f91df
rust: Implement error types for Rust protover implementation.
This will allow us to do actual error handling intra-crate in a more
rusty manner, e.g. propogating errors in match statements, conversion
between error types, logging messages, etc.

 * FIXES part of #24031: https://bugs.torproject.org/24031.
2018-04-02 19:24:32 +00:00
Isis Lovecruft
f2daf82794
rust: Fix ProtoSet and ProtoEntry to use the same DoS limits as C.
Previously, the limit for MAX_PROTOCOLS_TO_EXPAND was actually being applied
in Rust to the maximum number of version (total, for all subprotocols).
Whereas in C, it was being applied to the number of subprotocols that were
allowed.  This changes the Rust to match C's behaviour.
2018-04-02 19:20:40 +00:00
Isis Lovecruft
6eea0dc5f1
rust: Port all C protover_all_supported tests to Rust.
The behaviours still do not match, unsurprisingly, but now we know where a
primary difference is: the Rust is validating version ranges more than the C,
so in the C it's possible to call protover_all_supported on a ridiculous
version range like "Sleen=0-4294967294" because the C uses
MAX_PROTOCOLS_TO_EXPAND to count the number of *subprotocols* whereas the Rust
uses it to count the total number of *versions* of all subprotocols.
2018-04-02 19:20:39 +00:00
Isis Lovecruft
527a239863
tests: Run all existing protover tests in both languages.
There's now no difference in these tests w.r.t. the C or Rust: both
fail miserably (well, Rust fails with nice descriptive errors, and C
gives you a traceback, because, well, C).
2018-04-02 19:20:38 +00:00
Isis Lovecruft
22c65a0e4b
tests: Make inline comments in test_protover.c more accurate.
The DoS potential is slightly higher in C now due to some differences to the
Rust code, see the C_RUST_DIFFERS tags in src/rust/protover/tests/protover.rs.

Also, the comment about "failing at the splitting stage" in Rust wasn't true,
since when we split, we ignore empty chunks (e.g. "1--1" parses into
"(1,None),(None,1)" and "None" can't be parsed into an integer).

Finally, the comment about "Rust seems to experience an internal error" is only
true in debug mode, where u32s are bounds-checked at runtime.  In release mode,
code expressing the equivalent of this test will error with
`Err(ProtoverError::Unparseable)` because 4294967295 is too large.
2018-04-02 19:20:37 +00:00
Isis Lovecruft
6e353664dd
protover: Change protover_all_supported() to return only unsupported.
Previously, if "Link=1-5" was supported, and you asked protover_all_supported()
(or protover::all_supported() in Rust) if it supported "Link=3-999", the C
version would return "Link=3-999" and the Rust would return "Link=6-999".  These
both behave the same now, i.e. both return "Link=6-999".
2018-04-02 19:20:36 +00:00
Isis Lovecruft
fc2a42cc49
rust: Refactor protover::compute_for_old_tor().
During code review and discussion with Chelsea Komlo, she pointed out
that protover::compute_for_old_tor() was a public function whose
return type was `&'static CStr`.  We both agree that C-like parts of
APIs should:

1. not be exposed publicly (to other Rust crates),
2. only be called in the appropriate FFI code,
3. not expose types which are meant for FFI code (e.g. `*mut char`,
   `CString`, `*const c_int`, etc.) to the pure-Rust code of other
   crates.
4. FFI code (e.g. things in `ffi.rs` modules) should _never_ be called
   from pure-Rust, not even from other modules in its own crate
   (i.e. do not call `protover::ffi::*` from anywhere in
   `protover::protoset::*`, etc).

With that in mind, this commit makes the following changes:

 * CHANGE `protover::compute_for_old_tor()` to be
   visible only at the `pub(crate)` level.
 * RENAME `protover::compute_for_old_tor()` to
   `protover::compute_for_old_tor_cstr()` to reflect the last change.
 * ADD a new `protover::compute_for_old_tor()` function wrapper which
   is public and intended for other Rust code to use, which returns a
   `&str`.
2018-04-02 19:20:36 +00:00
Isis Lovecruft
9766d53cf9
rust: Refactor Rust implementation of protover_is_supported_here().
It was changed to take borrows instead of taking ownership.

 * REFACTOR `protover::ffi::protover_is_supported_here()` to use changed method
   signature on `protover::is_supported_here()`.
2018-04-02 19:20:35 +00:00
Isis Lovecruft
6f252e0986
rust: Refactor Rust impl of protover_compute_vote().
This includes a subtle difference in behaviour to the previous Rust
implementation, where, for each vote that we're computing over, if a single one
fails to parse, we skip it.  This now matches the current behaviour in the C
implementation.

 * REFACTOR `protover::ffi::protover_compute_vote()` to use
   new types and methods.
2018-04-02 19:20:34 +00:00
Isis Lovecruft
0a5494b81d
rust: Refactor Rust impl of protover_list_supports_protocol_or_later().
This includes a subtle difference in behaviour, as in 4258f1e18, where we return
(matching the C impl's return behaviour) earlier than before if parsing failed,
saving us computation in parsing the versions into a
protover::protoset::ProtoSet.

 * REFACTOR `protover::ffi::protover_list_supports_protocol_or_later()` to use
   new types and methods.
2018-04-02 19:20:33 +00:00
Isis Lovecruft
52c3ea5045
rust: Refactor Rust impl of protover_list_supports_protocol().
This includes a subtle difference in behaviour, as in 4258f1e18, where we return
(matching the C impl's return behaviour) earlier than before if parsing failed,
saving us computation in parsing the versions into a
protover::protoset::ProtoSet.

 * REFACTOR `protover::ffi::protover_list_supports_protocol()` to use new types
   and methods.
2018-04-02 19:20:32 +00:00
Isis Lovecruft
2f3a7376c0
rust: Refactor Rust impl of protover_all_supported().
This includes differences in behaviour to before, which should now more closely
match the C version:

 - If parsing a protover `char*` from C, and the string is not parseable, this
   function will return 1 early, which matches the C behaviour when protocols
   are unparseable.  Previously, we would parse it and its version numbers
   simultaneously, i.e. there was no fail early option, causing us to spend more
   time unnecessarily parsing versions.

 * REFACTOR `protover::ffi::protover_all_supported()` to use new types and
   methods.
2018-04-02 19:20:31 +00:00
Isis Lovecruft
15e59a1fed
rust: Refactor protover tests with new methods; note altered behaviours.
Previously, the rust implementation of protover considered an empty string to be
a valid ProtoEntry, while the C version did not (it must have a "=" character).
Other differences include that unknown protocols must now be parsed as
`protover::UnknownProtocol`s, and hence their entries as
`protover::UnvalidatedProtoEntry`s, whereas before (nearly) all protoentries
could be parsed regardless of how erroneous they might be considered by the C
version.

My apologies for this somewhat messy and difficult to read commit, if any part
is frustrating to the reviewer, please feel free to ask me to split this into
smaller changes (possibly hard to do, since so much changed), or ask me to
comment on a specific line/change and clarify how/when the behaviours differ.

The tests here should more closely match the behaviours exhibited by the C
implementation, but I do not yet personally guarantee they match precisely.

 * REFACTOR unittests in protover::protover.
 * ADD new integration tests for previously untested behaviour.
 * FIXES part of #24031: https://bugs.torproject.org/24031.
2018-04-02 19:20:31 +00:00
Isis Lovecruft
aa241e99de
rust: Refactor protover::is_supported_here().
This changes `protover::is_supported_here()` to be aware of new datatypes
(e.g. don't call `.0` on things which are no longer tuple structs) and also
changes the method signature to take borrows, making it faster, threadable, and
easier to read (i.e. the caller can know from reading the function signature
that the function won't mutate values passed into it).

 * CHANGE the `protover::is_supported_here()` function to take borrows.
 * REFACTOR the `protover::is_supported_here()` function to be aware of new
   datatypes.
 * FIXES part of #24031: https://bugs.torproject.org/24031
2018-04-02 19:20:30 +00:00
Isis Lovecruft
9abbd23df7
rust: Add new ProtoverVote type and refactor functions to methods.
This adds a new type for votes upon `protover::ProtoEntry`s (technically, on
`protover::UnvalidatedProtoEntry`s, because the C code does not validate based
upon currently known protocols when voting, in order to maintain
future-compatibility), and converts several functions which would have operated
on this datatype into methods for ease-of-use and readability.

This also fixes a behavioural differentce to the C version of
protover_compute_vote().  The C version of protover_compute_vote() calls
expand_protocol_list() which checks if there would be too many subprotocols *or*
expanded individual version numbers, i.e. more than MAX_PROTOCOLS_TO_EXPAND, and
does this *per vote* (but only in compute_vote(), everywhere else in the C seems
to only care about the number of subprotocols, not the number of individual
versions).  We need to match its behaviour in Rust and ensure we're not allowing
more than it would to get the votes to match.

 * ADD new `protover::ProtoverVote` datatype.
 * REMOVE the `protover::compute_vote()` function and refactor it into an
   equivalent-in-behaviour albeit more memory-efficient voting algorithm based
   on the new underlying `protover::protoset::ProtoSet` datatype, as
   `ProtoverVote::compute()`.
 * REMOVE the `protover::write_vote_to_string()` function, since this
   functionality is now generated by the impl_to_string_for_proto_entry!() macro
   for both `ProtoEntry` and `UnvalidatedProtoEntry` (the latter of which is the
   correct type to return from a voting protocol instance, since the entity
   voting may not know of all protocols being voted upon or known about by other
   voting parties).
 * FIXES part of #24031: https://bugs.torproject.org/24031

rust: Fix a difference in compute_vote() behaviour to C version.
2018-04-02 19:20:29 +00:00
Isis Lovecruft
26bafb3c33
rust: Add macro for impl ToString for {Unvalidated}ProtoEntry.
This implements conversions from either a ProtoEntry or an UnvalidatedProtoEntry
into a String, for use in replacing such functions as
`protover::write_vote_to_string()`.

 * ADD macro for implementing ToString trait for ProtoEntry and
   UnvalidatedProtoEntry.
 * FIXES part of #24031: https://bugs.torproject.org/24031
2018-04-02 19:20:28 +00:00
Isis Lovecruft
b786b146ed
rust: Add new protover::UnvalidatedProtoEntry type.
This adds a new protover::UnvalidatedProtoEntry type, which is the
UnknownProtocol variant of a ProtoEntry, and refactors several functions which
should operate on this type into methods.

This also fixes what was previously another difference to the C implementation:
if you asked the C version of protovet_compute_vote() to compute a single vote
containing "Fribble=", it would return NULL.  However, the Rust version would
return "Fribble=" since it didn't check if the versions were empty before
constructing the string of differences.  ("Fribble=" is technically a valid
protover string.)  This is now fixed, and the Rust version in that case will,
analogous to (although safer than) C returning a NULL, return None.

 * REMOVE internal `contains_only_supported_protocols()` function.
 * REMOVE `all_supported()` function and refactor it into
   `UnvalidatedProtoEntry::all_supported()`.
 * REMOVE `parse_protocols_from_string_with_no_validation()` and
   refactor it into the more rusty implementation of
   `impl FromStr for UnvalidatedProtoEntry`.
 * REMOVE `protover_string_supports_protocol()` and refactor it into
   `UnvalidatedProtoEntry::supports_protocol()`.
 * REMOVE `protover_string_supports_protocol_or_later()` and refactor
   it into `UnvalidatedProtoEntry::supports_protocol_or_later()`.
 * FIXES part of #24031: https://bugs.torproject.org/24031

rust: Fix another C/Rust different in compute_vote().

This fixes the unittest from the prior commit by checking if the versions are
empty before adding a protocol to a vote.
2018-04-02 19:20:27 +00:00
Isis Lovecruft
88b2f170e4
rust: Add new protover::ProtoEntry type which uses new datatypes.
This replaces the `protover::SupportedProtocols` (why would you have a type just
for things which are supported?) with a new, more generic type,
`protover::ProtoEntry`, which utilises the new, more memory-efficient datatype
in protover::protoset.

 * REMOVE `get_supported_protocols()` and `SupportedProtocols::tor_supported()`
   (since they were never used separately) and collapse their functionality into
   a single `ProtoEntry::supported()` method.
 * REMOVE `SupportedProtocols::from_proto_entries()` and reimplement its
   functionality as the more rusty `impl FromStr for ProtoEntry`.
 * REMOVE `get_proto_and_vers()` function and refactor it into the more rusty
   `impl FromStr for ProtoEntry`.
 * FIXES part of #24031: https://bugs.torproject.org/24031
2018-04-02 19:20:26 +00:00
Isis Lovecruft
811178434e
rust: Add new protover::UnknownProtocol type.
* ADD new type, protover::UnknownProtocol, so that we have greater type safety
   and our protover functionality which works with unsanitised protocol names is
   more clearly demarcated.
 * REFACTOR protover::Proto, renaming it protover::Protocol to mirror the new
   protover::UnknownProtocol type name.
 * ADD a utility conversion of `impl From<Protocol> for UnknownProtocol` so that
   we can easily with known protocols and unknown protocols simultaneously
   (e.g. doing comparisons, checking their version numbers), while not allowing
   UnknownProtocols to be accidentally used in functions which should only take
   Protocols.
 * FIXES part of #24031: https://bugs.torproject.org/24031
2018-04-02 19:20:12 +00:00
Isis Lovecruft
9925d2e687
rust: Implement more memory-efficient protover datatype.
* ADD new protover::protoset module.
 * ADD new protover::protoset::ProtoSet class for holding protover versions.
 * REMOVE protover::Versions type implementation and its method
   `from_version_string()`, and instead implement this behaviour in a more
   rust-like manner as `impl FromStr for ProtoSet`.
 * MOVE the `find_range()` utility function from protover::protover to
   protover::protoset since it's only used internally in the
   implementation of ProtoSet.
 * REMOVE the `contract_protocol_list()` function from protover::protover and
   instead refactor it (reusing nearly the entire thing, with minor superficial,
   i.e. non-behavioural, changes) into a more rusty
   `impl ToString for ProtoSet`.
 * REMOVE the `expand_version_range()` function from protover::protover and
   instead refactor it into a more rusty implementation of
   `impl Into<Vec<Version>> for ProtoSet` using the new error types in
   protover::errors.
 * FIXES part of #24031: https://bugs.torproject.org/24031.
2018-04-02 19:04:19 +00:00
Isis Lovecruft
b6059297d7
rust: Implement error types for Rust protover implementation.
This will allow us to do actual error handling intra-crate in a more
rusty manner, e.g. propogating errors in match statements, conversion
between error types, logging messages, etc.

 * FIXES part of #24031: https://bugs.torproject.org/24031.
2018-04-02 18:27:39 +00:00
Nick Mathewson
f9e32a2084 Remove an unnecessary event2 include.
The rest, are, unfortunately, necessary for now.
2018-04-02 11:11:34 -04:00
Nick Mathewson
f4bcf3f34c Remove event2/event.h include from compat_libevent.h
Only one module was depending on this include (test_helpers.c), and
it was doing so incorrectly.
2018-04-02 11:11:31 -04:00
Nick Mathewson
3df9545492 Merge branch 'maint-0.3.3' 2018-04-02 08:51:47 -04:00
Roger Dingledine
6190593256 use channel_is_client for create cell counts
When a relay is collecting internal statistics about how many
create cell requests it has seen of each type, accurately count the
requests from relays that temporarily fall out of the consensus.

(To be extra conservative, we were already ignoring requests from clients
in our counts, and we continue ignoring them here.)

Fixes bug 24910; bugfix on 0.2.4.17-rc.
2018-04-02 01:00:31 -04:00
Roger Dingledine
961d2ad597 dir auths no longer vote Guard if they're not voting V2Dir
Directory authorities no longer vote in favor of the Guard flag
for relays that don't advertise directory support.

Starting in Tor 0.3.0.1-alpha, Tor clients have been avoiding using
such relays in the Guard position, leading to increasingly broken load
balancing for the 5%-or-so of Guards that don't advertise directory
support.

Fixes bug 22310; bugfix on 0.3.0.6.
2018-04-02 00:20:01 -04:00
Roger Dingledine
0983c203e5 misc tiny fixes 2018-04-01 23:47:44 -04:00
Taylor Yu
596eed3715 Fix CID 1433643
Add a missing lock acquisition around access to queued_control_events
in control_free_all().  Use the reassign-and-unlock strategy as in
queued_events_flush_all().  Fixes bug 25675.  Coverity found this bug,
but only after we recently added an access to
flush_queued_event_pending.
2018-03-29 17:21:33 -05:00
Nick Mathewson
6d7c4c6ec2 Remove erroneous section heading "ExitPolicyDefault"
The anchor here was originally introduced to make sure that the
manpage would format correctly, but we had mistaken it for a section
anchor, and introduced a bogus section heading in 3563a2c819.

Fixes bug 25582; bugfix on 0.3.3.1-alpha.
2018-03-29 15:06:07 -04:00
Nick Mathewson
e8c1d4c8b0 Merge branch 'maint-0.3.3' 2018-03-29 15:00:46 -04:00
teor
6aaafb0672 Document torrc options that only work on v2 onion services
RendPostPeriod only works on v2 onion services.
HiddenServiceAuthorizeClient is not yet implemented for v3 onion services.

Closes ticket #25661, bugfix on 0.3.2.1-alpha.
2018-03-29 15:00:41 -04:00
Nick Mathewson
2c1afc2def Merge branch 'maint-0.3.3' 2018-03-29 14:59:01 -04:00
Nick Mathewson
4f473fadbd Merge branch 'bug25617_029' into maint-0.3.3 2018-03-29 14:58:58 -04:00
Nick Mathewson
5e8cf876e7 Merge branch 'maint-0.3.3'
"ours" merge to avoid version bump.
2018-03-29 11:24:13 -04:00
Nick Mathewson
2e9e91ebbf bump version to 0.3.3.4-alpha-dev 2018-03-29 11:24:02 -04:00