The function in charge of removing duplicate ORPorts from our configured ports
was skipping all non ORPorts port but only for the outer loop thus resulting
in comparing an ORPort with a non-ORPort which lead to problems.

For example, tor configured with the following would fail:

  ORPort auto
  DirPort auto

Both end up being the same configuration except that one is a OR listener and
one is a Dir listener. Thus because of the missing check in the inner loop,
they looked exactly the same and thus one is removed.

Fixes #40195

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

David Goulet authored 4 years ago and Nick Mathewson committed 4 years ago

First, this commit moves the launch_dummy_circuit_as_needed() function into
relay_find_addr.c and renames it to relay_addr_learn_from_dirauth(). This is
an attempt to centralize anything relate with address discovery in the right
module.

Second, when building a descriptor and we fail to discover our address,
immediately launch a dummy circuit to an authority in an attempt to learn our
descriptor.

It is still only done every 20 minutes even though the descriptor build is
done every minute. We ought to avoid load on the authority and if we can't
learn in the first place our address from them, chances are more things are
wrong.

Related to #40071

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

David Goulet authored 4 years ago and Nick Mathewson committed 4 years ago

Regularly, tor looks if its IP has changed. It does the entire auto discovery
process again. However, it is possible that it does not find anything.

Instead of thinking the IP changed to an unknown address, look at our cache
and see if that value has changed.

The reason for this is because if tor gets its address as a suggestion from a
directory authority, it is because the auto discovery failed and thus that
address should be consider for the IP change check.

Related to #40071

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

David Goulet authored 4 years ago and Nick Mathewson committed 4 years ago

Tor now can learn its address from a NETINFO cell coming from an authority.
Thus, instead from launching a dummy descriptor fetch to learn the address
from the directory response (unauthenticated), we simply now launch a one-hop
testing circuit.

Related to #40071

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

Commit c3a0f757 added this feature for ORPort
that we ignore any port that is not the family of our default address when
parsing the port. So if port_parse_config() was called with an IPv4 default
address, all IPv6 address would be ignored.

That makes sense for ORPort since we call twice port_parse_config() for
0.0.0.0 and [::] but for the rest of the ports, it is not good since a
perfectly valid configuration can be:

  SocksPort 9050
  SocksPort [::1]:9050

Any non-ORPort only binds by default to an IPv4 except the ORPort that binds
to both IPv4 and IPv6 by default.

The fix here is to always parse all ports within port_parse_config() and then,
specifically for ORPort, remove the duplicates or superseding ones. The
warning is only emitted when a port supersedes another.

A unit tests is added to make sure SocksPort of different family always exists
together.

Fixes #40183

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

Samanta Navarro authored 4 years ago and David Goulet committed 4 years ago

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)

It was deprecated 0.3.1.1-alpha.

According to #22473, nothing uses it.

Closes #22473.

The loop in the earlier patch would invoke undefined behavior in two
ways: First, it would check whether it was looking at a space before
it checked whether the pointer was in-range.  Second, it would let a
pointer reach a position _before_ the start of a string, which is
not allowed.

I've removed the assertion about empty messages: empty messages can
be their own warning IMO.

I've also added tests for this formatting code, to make sure it
actually works.

Closes #40063

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

Tracks the total number of established introduction circuit.

Related to #40063

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

The total number of rendezvous circuit created and the number of established
ones which is a gauge that decreases to keep an updated counter.

Related to #40063

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

Related to #40063

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

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

At this commit, a new service registers to the module and a store is created.
It also remove itself from the metrics module if it goes away.

In order to hook into the metrics subsystem, this commit attaches the HS
subsystem into the subsystem global list so its get_metrics() call can be
accessible.

HS initialization is still _not_ done through the subsys module as it is
likely require much more testing.

Related to #40063

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

If MetricsPort is defined, listen on it and handle the incoming request.

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

Related to #40063

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

First I began with a set of candidates:

  The client's _required_ list starts with all the protocols
  supported by every release in 0.2.9-stable through current
  master.

  The client's _required_ list starts with all the protocols
  supported by every release in 0.3.5-stable through current
  master.

  Everybody's _recommended_ list starts with all the protocols
  supported by every release in 0.3.5-stable through current master.

Then I removed the protocol versions that we do not actually want to
require or recommend:

  DirCache=1 (deprecated)
  HSDir=1, HSIntro=1-3, HSRend=1 (deprecated)
  (All HS* protocol requirements for clients)
  Link=1-3 (deprecated)
  LinkAuth=1 (obsolete)
  Relay=1 (obsolete)

Make it possible to specify multiple ConsensusParams torrc
lines.

Now directory authority operators can for example put the
main ConsensusParams config in one torrc file and then add to it
from a different torrc file.

Closes ticket 40164.

Affected entries are: EntryNodes, ExcludeNodes, ExcludeExitNodes,
ExitNodes, MiddleNodes, HSLayer2Nodes and HSLayer3Nodes.

Guinness authored 4 years ago and Nick Mathewson committed 4 years ago

Tor does not follow redirects when bootstraping so we encountered an
error.

Fixes #40053

Also, explain why it's relevant for bootstrapping.

This is a comments-only patch.

  Cons=1 is the old format of consensuses, without ed25519 keys. It
  is no longer required or recommended.

  Cons=2 is the new format of consensuses, with ed25519 keys. It
  is now required.

  (Similarly for Desc=1,2 and Microdesc=1,2)

No supported client or relay versions should be affected by this
change, since these versions are supported by clients and relays
running 0.2.9 and later.  It will only take effect once enough
authorities vote for it.

Closes ticket 40162.

This should make diffs easier to read.

These tests used a hardcoded vote with a hardcoded digest.  That
vote didn't have any pr lines, and so it is now invalid. I've
adjusted the testing code so that it mocks the signature-checking,
so that we can more easily change the contents of the vote.

This change breaks some unit tests; it's time to fix those in
subsequent commits.

(Or at least, to all those relay descriptions that derive from
format_node_description()).

Closes #22668.

David Goulet authored 4 years ago and Nick Mathewson committed 4 years ago

If at least one service is configured as a version 2, a log warning is emitted
once and only once.

Closes #40003

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

Alexander Hansen Færøy authored 5 years ago and David Goulet committed 4 years ago

This patch adds support for exposing the environment variables
`TOR_PT_OUTBOUND_BIND_ADDRESS_V4` and `TOR_PT_OUTBOUND_BIND_ADDRESS_V6` to
Pluggable Transport proccesses. These two values will contain the IPv4
and IPv6 address that the user have specified in torrc that they wish
the PT to use for all outgoing IP packets.

It is important to note here that it is up to the indvidual Pluggable
Transport if they are willing to honor these values or ignore them
completely.

One can test this feature using the following dummy PT written in POSIX
shell script:

    #!/bin/sh

    echo "LOG SEVERITY=warning MESSAGE=\"Value for IPv4: ${TOR_PT_OUTBOUND_BIND_ADDRESS_V4}\""
    echo "LOG SEVERITY=warning MESSAGE=\"Value for IPv6: ${TOR_PT_OUTBOUND_BIND_ADDRESS_V6}\""

    while true ; do
        sleep 1
    done

with the following entries in your torrc:

    OutboundBindAddressPT 203.0.113.4
    OutboundBindAddress 203.0.113.5
    OutboundBindAddressPT 2001:db8::4
    OutboundBindAddress 2001:db8::5

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

no actual changes