GitLab

This test makes sure that we reject "upload=" URLs with bad IP
addresses.

Also, add a warning when we can't parse the address.

This is part of an implementation for proposal 330.

This implementation doesn't handle authdirs' IPv6 dirports (yet).

(These aren't yet set or used.)

Now deprecated in libc >= 2.33

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

When trying to find our address to publish, we would log notice if we couldn't
find it from the cache but then we would look at the suggested cache (which
contains the address from the authorities) in which we might actually have the
address.

Thus that log notice was misplaced. Move it down after the suggested address
cache lookup.

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

Back in 0.4.5.1-alpha we added an `==` comparison, which isn't
portable.

Fixes bug #40298; bugfix on 0.4.5.1-alpha.

Now that exit relays don't allow exit connections to directory authority
DirPorts, the follow-up step is to make directory authorities stop doing
DirPort reachability checks.

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

Turns out, we forgot to add the METRICS connection type fo the finished
flushing handler.

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

The comment of that specific unit test wanted 4 ORPorts but for some reasons
we tested for 3 which before the previous commit related to #40289, test would
pass but it was in fact wrong.

Now the code is correct and 4 was in fact correct expected number of ports.

Related to #40289
Signed-off-by: David Goulet <dgoulet@torproject.org>

We were just looking at the family which is not correct because it is possible
to have two explicit ORPort for the same family but different addresses. One
example is:

  ORPort 127.0.0.1:9001 NoAdvertise
  ORPort 1.2.3.4:9001 NoListen

Thus, this patch now ignores ports that have different addresses iff they are
both explicits. That is, if we have this example, also two different
addresses:

  ORPort 9001
  ORPort 127.0.0.1:9001 NoAdvertise

The first one is implicit and second one is explicit and thus we have to
consider them for removal which in this case would remove the "ORPort 9001" in
favor of the second port.

Fixes #40289
Signe-off-by: David Goulet <dgoulet@torproject.org>

Fun bug where we thought we were using the default "false" value when an
implicit address was detected but if we had an explicit address before, the
flag was set to true and then we would only use that value.

And thus, for some configurations, implicit addresses would be flagged as
explicit and then configuring ports goes bad.

Related to #40289
Signed-off-by: David Goulet <dgoulet@torproject.org>

In other words, if PublishServerDescriptor is set to 0 and AssumeReachable to
1, then allow a relay to hold a RFC1918 address.

Reasons for this are documented in #40208

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

That comes from 685c4866 which added that
check correctly except for when we build a descriptor.

We already omit the IPv6 address, if we need to, when we encode the descriptor
but we need to keep the actual discovered address in the descriptor so we can
notice future IP changes and be able to assess that we are not publishable as
long as we don't specifically set the omit flag.

This lead to also having tor noticing that our IP changed from <nothing> (no
IPv6 in the descriptor) to a discovered one which would trigger every minute.

Fixes #40279, #40288
Signed-off-by: David Goulet <dgoulet@torproject.org>

Handle the EOF situation for a metrics connection. Furthermore, if we failed
to fetch the data from the inbuf properly, mark the socket as closed because
the caller, connection_process_inbuf(), assumes that we did so on error.

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

Previously we would warn in this case... but there's really no
justification for doing so, and it can only cause confusion.

Fixes bug #40281; bugfix on 0.4.0.1-alpha.

In two instances we must look at this flag:

1. When we build the descriptor so the IPv6 is NOT added to the descriptor in
   case we judge that we need to omit the address but still publish.

2. When we are deciding if the descriptor is publishable. This flags tells us
   that the IPv6 was not found reachable but we should still publish.

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

Closes #40221

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

Unreviewed build fix. Discussed the cnage on IRC with Nick.

This was a bad copy and paste error from the previous commit which
generated a duplicated entry error from practracker.

Unreviewed build fix.

See: tor#40275.

We solve this error by allowing the connection_exit_connect() function
to be 130 lines long.

Unreviewed build fix commit.

See: tor#40275.

While trying to resolve our CI issues, the Windows build broke with an
unused function error:

   src/test/test_switch_id.c:37:1: error: ‘unprivileged_port_range_start’
   defined but not used [-Werror=unused-function]

We solve this by moving the `#if !defined(_WIN32)` test above the
`unprivileged_port_range_start()` function defintion such that it is
included in its body.

This is an unreviewed commit.

See: tor#40275