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"
Works like the --enable-static-openssl/libevent options. Requires
--with-zlib-dir to be set. Note that other dependencies might still
pull in a dynamicly linked zlib, if you don't link them in statically
too.
asprintf() is a GNU extension that some BSDs have picked up: it does a printf
into a newly allocated chunk of RAM.
Our tor_asprintf() differs from standard asprintf() in that:
- Like our other malloc functions, it asserts on OOM.
- It works on windows.
- It always sets its return-field.
For most linking setups, this doesn't matter. But for some setups, when
statically linking openssl, it does matter, since you need to link things
with dependencies before you link things they depend on.
Fix for bug 1237.
This removes the Makefile.am from doc/design-paper and replaces it with
a static Makefile. We don't need to call it during the normal Tor build
process, as we don't need its targets normally. Keeping it around in
case we want to rebuild the pdf or ps files later.
This should be a very faithful conversion, preserving as much of the layout
of the old manpage as possible. This wasn't possible for the nt-service
and the DataDirectory/state parts. See a later commit for some small
cleanups.
Tiago Faria helped with the asciidoc conversion, big thanks!
On this OSX version, there is a stub mlockall() function
that doesn't work, *and* the declaration for it is hidden by
an '#ifdef _P1003_1B_VISIBLE'. This would make autoconf
successfully find the function, but our code fail to build
when no declaration was found.
This patch adds an additional test for the declaration.
This fixes bug 1147:
bionic doesn't have an actual implementation of mlockall();
mlockall() is merely in the headers but not actually in the library.
This prevents Tor compilation with the bionic libc for Android handsets.
Changes to directory request statistics:
- Rename GEOIP statistics to DIRREQ statistics, because they now include
more than only GeoIP-based statistics, whereas other statistics are
GeoIP-dependent, too.
- Rename output file from geoip-stats to dirreq-stats.
- Add new config option DirReqStatistics that is required to measure
directory request statistics.
- Clean up ChangeLog.
Also ensure that entry guards statistics have access to a local GeoIP
database.
This patch adds a new compat_libevent.[ch] set of files, and moves our
Libevent compatibility and utilitity functions there. We build them
into a separate .a so that nothing else in src/commmon depends on
Libevent (partially fixing bug 507).
Also, do not use our own built-in evdns copy when we have Libevent
2.0, whose evdns is finally good enough (thus fixing Bug 920).
Now, when you call tor --digests, it dumps the SHA1 digest of each
source file that Tor was built with. We support both 'sha1sum' and
'openssl sha1'. If the user is building from a tarball and they
haven't edited anything, they don't need any program that calculates
SHA1. If they _have_ modified a file but they don't have a program to
calculate SHA1, we try to build so we do not output digests.
GCC's interpretation of the C99 aliasing rules, to be charitable,
creates a dialect of C intended for a better programmers than I am
certain of my ability to be in all times. I just spent 2 hours
tracking down a platform-hyperspecific libevent bug that turned out to
be because of this, and darned if I ever want to do *that* again.
One of Linus's recent rants will give you a picture of why GCC's
behavior here can lead to fun surprises in your binaries:
http://lwn.net/Articles/316126/
svn:r18351
