GCC added an implicit-fallthrough warning a while back, where it
would complain if you had a nontrivial "case:" block that didn't end
with break, return, or something like that.  Clang recently added
the same thing.

GCC, however, would let you annotate a fall-through as intended by
any of various magic "/* fall through */" comments.  Clang, however,
only seems to like "__attribute__((fallthrough))".  Fortunately, GCC
accepts that too.

A previous commit in this branch defined a FALLTHROUGH macro to do
the right thing if GNUC is defined; here we replace all of our "fall
through" comments with uses of that macro.

This is an automated commit, made with the following perl one-liner:

  #!/usr/bin/perl -i -p
  s#/\* *falls? ?thr.*?\*/#FALLTHROUGH;#i;

(In order to avoid conflicts, I'm applying this script separately to
each maint branch. This is the 0.4.1 version.)

GCC added an implicit-fallthrough warning a while back, where it
would complain if you had a nontrivial "case:" block that didn't end
with break, return, or something like that.  Clang recently added
the same thing.

GCC, however, would let you annotate a fall-through as intended by
any of various magic "/* fall through */" comments.  Clang, however,
only seems to like "__attribute__((fallthrough))".  Fortunately, GCC
accepts that too.

A previous commit in this branch defined a FALLTHROUGH macro to do
the right thing if GNUC is defined; here we replace all of our "fall
through" comments with uses of that macro.

This is an automated commit, made with the following perl one-liner:

  #!/usr/bin/perl -i -p
  s#/\* *falls? ?thr.*?\*/#FALLTHROUGH;#i;

Proposal 289 prevents SENDME-flooding by requiring the other side to
authenticate the data it has received.  But this data won't actually
be random if they are downloading a known resource.  "No problem",
we said, "let's fell the empty parts of our cells with some
randomness!" and we did that in #26871.

Unfortunately, if the relay data payloads are all completely full,
there won't be any empty parts for us to randomize.

Therefore, we now pick random "randomness windows" between
CIRCWINDOW_INCREMENT/2 and CIRCWINDOW_INCREMENT. We remember whether we have
sent a cell containing at least 16 bytes of randomness in that window.  If we
haven't, then when the window is exhausted, we send one.  (This window approach
is designed to lower the number of rng checks we have to do.  The number 16 is
pulled out of a hat to change the attacker's guessing difficulty to
"impossible".)

Implements 28646.

When a circuit is marked for close, check to see if any of our padding
machines want to take ownership of it and continue padding until the machine
hits the END state.

For safety, we also ensure that machines that do not terminate are still
closed as follows: Because padding machine timers are UINT32_MAX in size, if
some sort of network event doesn't happen on a padding-only circuit within
that time, we can conclude it is deadlocked and allow
circuit_expire_old_circuits_clientside() to close it.

If too much network activity happens, then per-machine padding limits can be
used to cease padding, which will cause network cell events to cease, on the
circuit, which will cause circpad to abandon the circuit as per the above time
limit.

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

Again everything is moved, apart from a free line using ->private.

This commit only moves code, and makes one function public.

This makes tor remember the last seen digest of a cell if that cell is the
last one before a SENDME on the Exit side.

Closes #26839

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

Also, split the formatting code shared by control.c and
control_events.c into controller_fmt.c.

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>

Co-authored-by: George Kadianakis <desnacked@riseup.net>

Add a publish-subscribe subsystem to publish messages about changes to
origin circuits.

Functions in circuitbuild.c and circuitlist.c publish messages to this
subsystem.

Move circuit event constants out of control.h so that subscribers
don't have to include all of control.h to take actions based on
messages they receive.

Part of ticket 27167.

When storing a descriptor in the client cache, if we are about to replace an
existing descriptor, make sure to close every introduction circuits of the old
descriptor so we don't have leftovers lying around.

Ticket 27471 describes a situation where tor is sending an INTRODUCE1 cell on
an introduction circuit for which it doesn't have a matching intro point
object (taken from the descriptor).

The main theory is that, after a new descriptor showed up, the introduction
points changed which led to selecting an introduction circuit not used by the
service anymore thus for which we are unable to find the corresponding
introduction point within the descriptor we just fetched.

Closes #27471.

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

It differs from the rest of the rephist code in that it's actually
necessary for Tor to operate, so it should probably go somewhere
else.  I'm not sure where yet, so I'll leave it in the same
directory, but give it its own file.

Parts of this C file naturally belong in dircache, dirclient, and
dircommon: so, move them there.

The main.c code is responsible for initialization and shutdown;
the mainloop.c code is responsible for running the main loop of Tor.

Splitting the "generic event loop" part of mainloop.c from the
event-loop-specific part is not done as part of this patch.

The parts for handling cell formats should be in src/core/or.

The parts for handling onionskin queues should be in src/core/or.

Only the crypto wrapper belongs in src/core/crypto.

I am very glad to have written this script.

This commit won't build yet -- it just puts everything in a slightly
more logical place.

The reasoning here is that "src/core" will hold the stuff that every (or
nearly every) tor instance will need in order to do onion routing.
Other features (including some necessary ones) will live in
"src/feature".  The "src/app" directory will hold the stuff needed
to have Tor be an application you can actually run.

This commit DOES NOT refactor the former contents of src/or into a
logical set of acyclic libraries, or change any code at all.  That
will have to come in the future.

We will continue to move things around and split them in the future,
but I hope this lays a reasonable groundwork for doing so.

These were mostly cases where our previous macros had been casting,
and the values that we were trying to printf were not in fact
uint64_t.

The standard is printf("%"PRIu64, x);

or.h should really include only the minimum of stuff from or/*,
common/*, and lib/*.

More modules use this than I had expected!