We need to mitigate slow scheduling of Travis macOS jobs.

Closes ticket 32177.

Since Travis macOS has IPv6 support (and Travis Linux does not), chutney
will now run its IPv6 networks as part of Travis CI.

But since chutney is slow, don't wait for the macOS chutney to finish.
(Travis have fixed the duplicate notification bug in fast_finish. So we
can use fast_finish and allow_failure to finish early. Unfortunately,
allow_failure also means we ignore failures in macOS chutney.)

Also make sure that we have:
* a compile on each platform, with each compiler,
* a check on each platform, and
* a check on each compiler.

Finally, sort builds: allow fail last, macOS first, slowest first.

Closes ticket 30860.
Closes ticket 31859 for 0.2.9.

Part of 31859.

The jobs should be the same, but Travis may display them differently.

Part of 31859.

Closes #31673

New IP address from 194.109.206.212 to 45.66.33.45.

Signed request from Alex de Joode, operator of dizum:
https://trac.torproject.org/projects/tor/ticket/31406



Published descriptor by dizum on August 12th, 2019:

--
r dizum fqbq1v2DCDxTj0QDi7+gd1h911U GZmZtCLaPDQNxkhIFj8UcgTRAuA 2019-08-12 15:28:40 45.66.33.45 443 80
s Authority Fast Running Stable V2Dir Valid
v Tor 0.4.0.5
pr Cons=1-2 Desc=1-2 DirCache=1-2 HSDir=1-2 HSIntro=3-4 HSRend=1-2 Link=1-5 LinkAuth=1,3 Microdesc=1-2 Relay=1-2 Padding=1
w Bandwidth=20 Unmeasured=1
p reject 1-65535
--

Finally, confirmed by DNS:

  $ dig +short tor.dizum.com
  45.66.33.45

Closes #31406

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

Fixes bug 31374; bugfix on 0.2.9.1-alpha.

My previous fix removed a comparison, which would have caused us to
warn about every skew instead of skews of over an hour.

On some windows builds, time_t is 64 bits but long is not.  This is
causing appveyor builds to fail.

Also, one of our uses of labs() on time_t was logically incorrect:
it was telling us to accept NETINFO cells up to three minutes
_before_ the message they were responding to, which doesn't make
sense.

This patch adds a time_abs() function that we should eventually move
to intmath.h or something.  For now, though, it will make merges
easier to have it file-local in channeltls.c.

Fixes bug 31343; bugfix on 0.2.4.4-alpha.

Linux is the first item in the os matrix, so we don't need to specify
it under matrix: include: .

Part of 29280.

Part of 29280.

Part of 29280.

Replace the 157 fallbacks originally introduced in Tor 0.3.5.6-rc
in December 2018 (of which ~122 were still functional), with a
list of 148 fallbacks (70 new, 78 existing, 79 removed) generated
in June 2019.

Closes ticket 28795.

Note that we created extra lists from DE and US, but they didn't add
any more fallbacks when we tried to merge them.

Update the fallback directory mirrors by merging the current list with:
fallback_dirs_2019-06-28-08-58-39_AU_f0437a39ddbc8459.inc

Part of 28795, see that ticket for logs.

Update the fallback directory mirrors by replacing the old list with:
fallback_dirs_2019-06-25-11-49-10_AU_a37adb956fbb5cd2.inc

Part of 28795, see that ticket for logs.

Previously we had "make check" launched whenever DISTCHECK was
false.  Now we'd like to turn it off in a few other circumstances,
like running chutney.  Maybe stem too?

We think this bug can only be triggered by modifying a local file.

Fixes bug 30781; bugfix on 0.2.0.8-alpha.

Tobias Stoeckmann authored 5 years ago and Nick Mathewson committed 5 years ago

If tor is compiled on a system with neither vasprintf nor _vscprintf,
the fallback implementation exposes a logic flaw which prevents
proper usage of strings longer than 127 characters:

* tor_vsnprintf returns -1 if supplied buffer is not large enough,
  but tor_vasprintf uses this function to retrieve required length
* the result of tor_vsnprintf is not properly checked for negative
  return values

Both aspects together could in theory lead to exposure of uninitialized
stack memory in the resulting string. This requires an invalid format
string or data that exceeds integer limitations.

Fortunately tor is not even able to run with this implementation because
it runs into asserts early on during startup. Also the unit tests fail
during a "make check" run.

Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>

  [backported to 0.2.9 by nickm]

See: https://blog.travis-ci.com/2018-11-19-required-linux-infrastructure-migration