Alexander Hansen Færøy authored 7 years ago and Nick Mathewson committed 6 years ago

This patch changes the algorithm of compute_real_max_mem_in_queues() to
use 0.4 * RAM iff the system has more than or equal to 8 GB of RAM, but
will continue to use the old value of 0.75 * RAM if the system have less
than * GB of RAM available.

This patch also adds tests for compute_real_max_mem_in_queues().

See: https://bugs.torproject.org/24782

Alexander Hansen Færøy authored 7 years ago and David Goulet committed 6 years ago

This patch makes compute_real_max_mem_in_queues use the STATIC macro,
which allows us to test the function.

See: https://bugs.torproject.org/24782

Alexander Hansen Færøy authored 7 years ago and David Goulet committed 6 years ago

This patch makes get_total_system_memory mockable, which allows us to
alter the return value of the function in tests.

See: https://bugs.torproject.org/24782

The old single-underscore names remain as a deprecated synonym.

Fixes bug 25581; bugfix on 0.3.3.1-alpha.

Mike Perry authored 7 years ago and Nick Mathewson committed 6 years ago

We removed this by breaking them out from general in #13837.

This patch lifts the list of default directory authorities from config.c
into their own auth_dirs.inc file, which is then included in config.c
using the C preprocessor.

Patch by beastr0.

See: https://bugs.torproject.org/24854

Fixes bug 25732; bugfix on 0.3.3.2-alpha when strings.rs was
introduced.

Closes ticket 25296; bugfix on 0.2.2.7-alpha when these manpage
entries were introduced.

By default, we want to look at the crates directory of the
submodule, not the toplevel of the submodule.  Fixes bug 25679;
bugfix on 0.3.3.1-alpha.

Some anchor don't appear in the final man page so document those so we
understand why we do that in the future.

Part of #25582

Signed-off-by: David Goulet <dgoulet@torproject.org>

Dhalgren authored 7 years ago and Nick Mathewson committed 7 years ago

Also don't give up on a resolver as quickly if multiple are configured.

(cherry picked from commit 5a8cdec3)

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.

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.

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).

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.

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".

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`.

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()`.

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.