The function compat_getdelim_ is used for tor_getline if tor is compiled
on a system that lacks getline and getdelim. These systems should be
very rare, considering that getdelim is POSIX.

If this system is further a 32 bit architecture, it is possible to
trigger a double free with huge files.

If bufsiz has been already increased to 2 GB, the next chunk would
be 4 GB in size, which wraps around to 0 due to 32 bit limitations.

A realloc(*buf, 0) could be imagined as "free(*buf); return malloc(0);"
which therefore could return NULL. The code in question considers
that an error, but will keep the value of *buf pointing to already
freed memory.

The caller of tor_getline() would free the pointer again, therefore
leading to a double free.

This code can only be triggered in dirserv_read_measured_bandwidths
with a huge measured bandwith list file on a system that actually
allows to reach 2 GB of space through realloc.

It is not possible to trigger this on Linux with glibc or other major
*BSD systems even on unit tests, because these systems cannot reach
so much memory due to memory fragmentation.

This patch is effectively based on the penetration test report of
cure53 for curl available at https://cure53.de/pentest-report_curl.pdf
and explained under section "CRL-01-007 Double-free in aprintf() via
unsafe size_t multiplication (Medium)".

Fixes bug 29922; bugfix on 0.2.9.3-alpha when we tried to capture
all these warnings.  No need to backport any farther than 0.3.5,
though -- these warnings don't cause test failures before then.

This one was tricky to find because apparently it only happened on
_some_ windows builds.

We need to keep the gcno files, because they are created at compile time.

When classifying a client's selection of TLS ciphers, if the client
ciphers are not yet available, do not cache the result. Previously,
we had cached the unavailability of the cipher list and never looked
again, which in turn led us to assume that the client only supported
the ancient V1 link protocol.  This, in turn, was causing Stem
integration tests to stall in some cases.  Fixes bug 30021; bugfix
on 0.2.4.8-alpha.

(Travis terminates the job after 10 minutes of no output.)

Diagnostic for 29437.

Fixes bug 30011; bugfix on 0.3.5.4-alpha.

Merge the moved coverage line from 29036 with the stem changes in
maint-0.3.5.

And add some useful comments

rl1987 authored 6 years ago and teor committed 6 years ago

Also, refrain from caching target/.

See: https://levans.fr/rust_travis_cache.html

And fix a comment.

See:
https://gcc.gnu.org/onlinedocs/gcc/Gcov-Data-Files.html#Gcov-Data-Files

Otherwise, "make check-changes" will complain when we backport the change.

We need a recent test-network.sh to use new chutney features in CI.

Fixes bug 29703; bugfix on 0.2.9.1-alpha.

Part of 29806.

Copy and paste the vote=0 code from the old src/or/dirserv.c
to the new src/feature/dirauth/bwauth.c.

juga authored 6 years ago and teor committed 6 years ago

so that the relays that would be "excluded" from the bandwidth
file because of something failed can be included to diagnose what
failed, without still including these relays in the bandwidth
authorities vote.

Closes #29806.

Since we have moved coveralls to the script target the entire build will
now fail if coveralls fail. We handle it more gracefully by echo'ing the
failure instead of doing a hard-failure.

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

This should ensure that GCDA files are never entering the cache of
Travis CI.

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