Uses libscrypt when found; otherwise, we don't have scrypt and we
only support openpgp rfc2440 s2k hashing, or pbkdf2.
Includes documentation and unit tests; coverage around 95%. Remaining
uncovered code is sanity-checks that shouldn't be reachable fwict.
c99 lets us do neat stuff like:
{
int j, k;
foo(&j, &k);
int z = j + k;
}
and also
struct point { int x; int y; };
struct point pt = { .x=5, .y=5 };
This commit makes the configure scripts check to make sure your
compiler implements them. It also disables our longstanding warning
about midblock declarations.
Closes ticket 13233.
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
We added some AS_VAR_IF-based checks to detect whether we have
managed to compile (but not link) with stack-protector. On autoconf
before 2.63, we don't have AS_VAR_IF, so we just have to let the
user get a compile error rather than a helpful "find libssp" error.
Fixes bug 12693; bugfix on 0.2.5.2-alpha (commit 21ac292820)
When building with bufferevents enabled, configure.ac throws an
error if "$ac_cv_header_event2_bufferevent_ssl_h" is not set to
"yes". However, nowhere was AC_CHECK_HEADERS(event2/bufferevent_ssl.h)
done. This commit adds the check.
Long ago we supported systems where there was no support for
threads, or where the threading library was broken. We shouldn't
have do that any more: on every OS that matters, threads exist, and
the OS supports running threads across multiple CPUs.
This resolves tickets 9495 and 12439. It's a prerequisite to making
our workqueue code work better, since sensible workqueue
implementations don't split across multiple processes.
Apparently, there exist cross-compiling environments for arm7 where
you can compile a 64x64->128 multiply, but not link it.
Fixes bug 11729; bugfix on 0.2.4.8-alpha. Patch from 'conradev'.
Libevent uses an arc4random implementation (I know, I know) to
generate DNS transaction IDs and capitalization. But it liked to
initialize it either with opening /dev/urandom (which won't work
under the sandbox if it doesn't use the right pointer), or with
sysctl({CTL_KERN,KERN_RANDOM,RANDOM_UUIC}). To make _that_ work, we
were permitting sysctl unconditionally. That's not such a great
idea.
Instead, we try to initialize the libevent PRNG _before_ installing
the sandbox, and make sysctl always fail with EPERM under the
sandbox.
This should make more platforms (in particular, ones with compilers
where -fomit-frame-pointer is on by default but table generation
isn't) support backtrace generation. Thanks to cypherpunks for this
one.
Fixes bug 11047; bugfix on 0.2.5.2-alpha.
This M4 module lets us learn the right way (out of at least 18
possibilities) to extract the current PC for stack-trace-fixup-in-signal
purposes. The Google Performance Tools license is 3-clause BSD.
On platforms with the backtrace/backtrace_symbols_fd interface, Tor
can now dump stack traces on assertion failure. By default, I log
them to DataDir/stack_dump and to stderr.
If you pass the --enable-coverage flag on the command line, we build
our testing binaries with appropriate options eo enable coverage
testing. We also build a "tor-cov" binary that has coverage enabled,
for integration tests.
On recent OSX versions, test coverage only works with clang, not gcc.
So we warn about that.
Also add a contrib/coverage script to actually run gcov with the
appropriate options to generate useful .gcov files. (Thanks to
automake, the .o files will not have the names that gcov expects to
find.)
Also, remove generated gcda and gcno files on clean.
This is mainly a matter of automake trickery: we build each static
library in two versions now: one with the TOR_UNIT_TESTS macro
defined, and one without. When TOR_UNIT_TESTS is defined, we can
enable mocking and expose more functions. When it's not defined, we
can lock the binary down more.
The alternatives would be to have alternate build modes: a "testing
configuration" for building the libraries with test support, and a
"production configuration" for building them without. I don't favor
that approach, since I think it would mean more people runnning
binaries build for testing, or more people not running unit tests.
This is a bashism; on systems where sh is not bash (eg., non-Linux, or
Ubuntu using dash), this breaks with a syntax error. This also doesn't
work properly in bash: only the first item is iterated on.
If USE_ASCIIDOC is enabled but asciidoc isn't present and manpages
aren't already generated, it'll throw a warning during configure.
Works with the current git / tarball split.
Caveat: regular_mans are listed in the configure.ac
See #6506
Clang 3.2 does constant-folding and variable substitution to determine
that the program is equivalent to "return 1". Splitting the 128-bit
math into a new function seems sufficient to fix this.
In 81d69f4c2d (0.2.21-alpha) we added a compile-time check for
a (totally broken) signed size_t. In 0e597471af (not yet released)
I switched to a better configure-time check, which stored its output
in a different variable. I didn't change the code which looked at
the output, however.
This bug is not in any released version of Tor, and would not affect
anybody with a working Tor.
Inspired by #8042.
As far as I know, OpenVMS is the only place you're likely to hit an
unsigned time_t these days, and Tor's VMS support
is... lacking. Still worth letting people know about it, though.
This is allowed by the C statndard, which permits you to represent
doubles any way you like, but in practice we have some code that
assumes that memset() clears doubles in structs. Noticed as part of
7802 review; see 8081 for more info.
We want to use donna-c64 when we have a GCC with support for
64x64->uint128_t multiplying. If not, we want to use libnacl if we
can, unless it's giving us the unsafe "ref" implementation. And if
that isn't going to work, we'd like to use the
portable-and-safe-but-slow 32-bit "donna" implementation.
We might need more library searching for the correct libnacl,
especially once the next libnacl release is out -- it's likely to have
bunches of better curve25519 implementations.
I also define a set of curve25519 wrapper functions, though it really
shouldn't be necessary.
We should eventually make the -donna*.c files get build with
-fomit-frame-pointer, since that can make a difference.
