This is in preparation for a big patch series removing the entire Naming
system from Tor. In its wake, the approved-routers file is being
deprecated, and a replacement option to allow only pre-approved routers
is not being implemented.
Otherwise, when we're out of input *and* finalizing, we might report
TOR_ZLIB_OK erroneously and not finalize the buffer.
(I don't believe this can happen in practice, with our code today:
write_to_buf_zlib ensures that we are never trying to write into a
completely empty buffer, and zlib says "Z_OK" if you give it even
one byte to write into.)
Fixes bug 11824; bugfix on 0.1.1.23 (06e09cdd47).
torrc.minimal is now the one that should change as infrequently as
possible. To schedule an change to go into it eventually, make your
change to torrc.minimal.in-sample.
torrc.sample is now the volatile one: we can change it to our hearts'
content.
Closes ticket #11144
This implements a feature from bug 13000. Instead of starting a bwauth
run with this wrong idea about their bw, relays should do the self-test
and then get measured.
When a tor relay starts up and has no historical information about its
bandwidth capability, it uploads a descriptor with a bw estimate of 0.
It then starts its bw selftest, but has to wait 20 minutes to upload the
next descriptor due to the MAX_BANDWIDTH_CHANGE_FREQ delay. This change
should mean that on average, relays start seeing meaningful traffic a
little quicker, since they will have a higher chance to appear in the
consensus with a nonzero bw.
Patch by Roger, changes file and comment by Sebastian.
We're calling mallocfn() and reallocfn() in the HT_GENERATE macro
with the result of a product. But that makes any sane analyzer
worry about overflow.
This patch keeps HT_GENERATE having its old semantics, since we
aren't the only project using ht.h. Instead, define a HT_GENERATE2
that takes a reallocarrayfn.
Most of these are in somewhat non-obvious code where it is probably
a good idea to initialize variables and add extra assertions anyway.
Closes 13036. Patches from "teor".
This commit attempts to satisfy nickm's comment on check_private_dir() permissions:
https://trac.torproject.org/projects/tor/ticket/11291#comment:12
"""check_private_dir() ensures that the directory has bits 0700 if CPD_CHECK_MODE_ONLY is not set. Shouldn't it also ensure that the directory has bits 0050 if CPD_CHECK_MODE_ONLY is not set, and CPD_GROUP_READ is set?"""
It's now a protocol-warn, since there's nothing relay operators can
do about a client that sends them a malformed create cell.
Resolves bug 12996; bugfix on 0.0.6rc1.
Any error when acquiring the CryptoAPI context should get treated as
bad. Also, this one can't happen for the arguments we're giving.
Fixes bug 10816; bugfix on 0.0.2pre26.
Previously, we had done this only in the connection_free() case, but
when we called connection_free_() directly from
connections_free_all(), we didn't free the connections.