This should prevent some asserts and storage of incorrect build times
for the cases where Tor is suspended during a circuit construction, or
just after completing a circuit. The idea is that if the circuit
build time is much greater than we would have cut it off at, we probably
had a suspend event along this codepath, and we should discard the
value.
In case we decide that the timeout rate is now too high due to our
change of the max synthetic quantile value, this consensus parameter
will allow us to restore it to the previous value.
This is for the other issue we saw in Bug 1335. A large number of high
timeouts were causing the timeout calculation to slowly drift upwards,
especially in conditions of load. This fix repeatedly regenerates all of
our synthetic timeouts whenever the timeout changes, to try to prevent
drift.
It also lowers the timeout cap to help for some cases of Bug 1245, where
some timeout values were so large that we ended up allocating a ton of
scratch memory to count the histogram bins.
The downside is that lowering this cap is affecting our timeout rate.
Unfortunately, the buildtimeout quantile is now higher than the actual
completion rate by what appears to be about 7-10%, which probably
represents the skew in the distribution due to lowering this synthetic
cap.
In my state files, I was seeing several peaks, probably due to different
guards having different latency. This change is meant to better capture
this behavior and generate more reasonable timeouts when it happens. It
is improving the timeout values for my collection of state files.
Build on Ubuntu 10.04 64-bit was failing:
util.c: In function ‘parse_http_time’:
util.c:1370: error: not protecting function: no buffer at least 8 bytes long
We don't want to lose -Werror, and we don't care too much about the
added overhead of protecting even small buffers, so let's simply turn on
SSP for all buffers.
Thanks to Jacob Appelbaum for the pointer and SwissTorExit for the
original report.
Signed-off-by: Andy Isaacson <adi@hexapodia.org>
This patch adds support for two new configure options:
'--enable-gcc-hardening'
This sets CFLAGS to include:
"-D_FORTIFY_SOURCE=2 -fstack-protector-all"
"-fwrapv -fPIE -Wstack-protector -Wformat -Wformat-security"
"-Wpointer-sign"
It sets LDFLAGS to include:
"-pie"
'--enable-linker-hardening'
This sets LDFLAGS to include:
" -z relro -z now"
The main changes are to explain how we use git branches, how we use
changes files, and what should go into a patch. Putting these in
HACKING means that we shouldn't need to constantly refer to the or-dev
emails where we explain this stuff.
what's happening here is that we're fetching certs for obsolete
authorities -- probably legacy signers in this case. but try to
remain general in the log message.
It's natural for the definition of bandwidth_rule_t to be with the functions
that actually care about its values. Unfortunately, this means declaring
bandwidth_rate_rule_to_string() out of sequence. Someday we'll just rename
reasons.c to strings.c, and put it at the end of or.h, and this will all be
better.
1) mingw doesn't have _vscprintf(); mingw instead has a working snprintf.
2) windows compilers that _do_ have a working _vscprintf spell it so; they do
not spell it _vcsprintf().
