Samanta Navarro authored Nov 11, 2020 and David Goulet committed Nov 12, 2020

Typos found with codespell.

Please keep in mind that this should have impact on actual code
and must be carefully evaluated:

src/core/or/lttng_circuit.inc
-    ctf_enum_value("CONTROLER", CIRCUIT_PURPOSE_CONTROLLER)
+    ctf_enum_value("CONTROLLER", CIRCUIT_PURPOSE_CONTROLLER)

This is an automated commit, generated by this command:

./scripts/maint/rename_c_identifier.py \
        EXPOSE_CLEAN_BACKTRACE BACKTRACE_PRIVATE \
        TOR_CHANNEL_INTERNAL_ CHANNEL_OBJECT_PRIVATE \
        CHANNEL_PRIVATE_ CHANNEL_FILE_PRIVATE \
        EXPOSE_ROUTERDESC_TOKEN_TABLE ROUTERDESC_TOKEN_TABLE_PRIVATE \
        SCHEDULER_PRIVATE_ SCHEDULER_PRIVATE

These changes were created using the "make autostyle" from
32522, and then split into commits.

Fake circuits are created everywhere in the unit tests. This is an attempt at
centralizing a "fake circuit creation" API like fakechans.c does for channel.

This commit introduces fakecircs.c and changes test_relay.c and
test_circpadding.c which were using roughly the same code.

This will allow easier OR circuit creation for the future tests in
test_circuitmux.c

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

As per David's review.

Bug not in any released Tor.

The client side had garbage histograms and deadcode here, too. That code has
been removed.

The tests have also been updated to properly test the intro circ by sending
padding from the relay side to the client, and verifying that both shut down
when padding was up. (The tests previously erroneously tested only the client
side of intro circs, which actually were supposed to be doing nothing).

We are gonna use this function to register our new machine.

Also test circpad expiry safeguard.

Our other tests tested state lengths against padding packets, and token counts
against non-padding packets. This test checks state lengths against
non-padding packets (and also padding packets too), and checks token counts
against padding packets (and also non-padding packets too).

The next three commits are needed to make this test pass (it found 3 bugs).
Yay?

Deliver nonpadding events instead of calling token removal functions.

This reverts commit ab8b80944967ee5a6a0c45dbf61839cf257bfe44.

Some of these functions are now public and cpath-specific so their name should
signify the fact they are part of the cpath module:

assert_cpath_layer_ok -> cpath_assert_layer_ok
assert_cpath_ok -> cpath_assert_ok
onion_append_hop -> cpath_append_hop
circuit_init_cpath_crypto -> cpath_init_circuit_crypto
circuit_free_cpath_node -> cpath_free
onion_append_to_cpath -> cpath_extend_linked_list

We are using an opaque pointer so the structure needs to be allocated on the
heap. This means we now need a constructor for crypt_path_t.

Also modify all places initializing a crypt_path_t to use the constructor.

This commit only moves code.

This reverts commit 387d9448.

This test was disabled in 0.4.0 and later, but the fix in #29298 was only
merged to 0.4.1. So this test will never be re-enabled in 0.4.0.

Part of 29500.

Mike Perry authored Apr 05, 2019 and teor committed Apr 05, 2019

Our monotime mocking forces us to call monotime_init() *before* we set the
mocked time value. monotime_init() thus stores the first ratchet value at
whatever the platform is at, and then we set fake mocked time to some later
value.

If monotime_init() gets a value from the host that is greater than what we
choose to mock time at for our unittests, all subsequent monotime_abosolute()
calls return zero, which breaks all unittests that depend on time moving
forward by updating mocked monotime values.

So, we need to adjust our mocked time to take the weird monotime_init() time
into account, when we set fake time.

Mike Perry authored Mar 04, 2019 and teor committed Apr 05, 2019

Hopefully this will stop monotime_absolute_usec() from returning 0 on some
platforms in the tests.

Mike Perry authored Feb 27, 2019 and teor committed Apr 05, 2019

Cancel the padding timer by changing order of sent vs recv (sent cancels).

George Kadianakis authored Mar 13, 2019 and teor committed Mar 22, 2019

The name of circpad_machine_state_t was very confusing since it was conflicting
with circpad_state_t and circpad_circuit_state_t.

Right now here is the current meaning of these structs:

      circpad_state_t -> A state of the state machine.
      circpad_machine_runtime_t -> The current mutable runtime info of the state machine.
      circpad_circuit_state_t -> Circuit conditions based on which we should apply a machine to the circuit

George Kadianakis authored Mar 13, 2019 and teor committed Mar 21, 2019

This is something we should think about harder, but we probably want dormant
mode to be more powerful than padding in case a client has been inactive for a
day or so. After all, there are probably no circuits open at this point and
dormant mode will not allow the client to open more circuits.

Furthermore, padding should not block dormant mode from being activated, since
dormant mode relies on SocksPort activity, and circuit padding does not mess
with that.

David Goulet authored Jan 29, 2019 and Roger Dingledine committed Mar 14, 2019

They are simply not used apart from assigning a pointer and asserting on the
pointer depending on the cell direction.

Closes #29196.

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

George Kadianakis authored Feb 25, 2019 and Nick Mathewson committed Mar 13, 2019

They were causing the following warnings in circuitpadding/circuitpadding_sample_distribution:

     src/lib/math/prob_distr.c:1311:17: runtime error: division by zero
     SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/lib/math/prob_distr.c:1311:17 in
     src/lib/math/prob_distr.c:1219:49: runtime error: division by zero
     SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/lib/math/prob_distr.c:1219:49 in

because the distributions were called with erroneous parameters (e.g. geometric
distribution with p=0).

We now defined these test probability distributions with more realistic
parameters.

As far as the circuitpadding_sample_distribution() test is concerned, it
doesn't matter if the distributions return values outside of [0,10] since we
already restrict the values into that interval using min=0 and max=10 (and RTT
estimate is disabled).