nihilist/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-11-11 13:43:47 +01:00
Code Issues Packages Projects Releases Wiki Activity
518b0b3c5f
tor/src/common/include.am

149 lines
4.3 KiB
Plaintext
Raw Normal View History

Move to non-recursive make This gives us a few benefits: 1) make -j clean all this will start working, as it should. It currently doesn't. 2) increased parallel build recursive make will max out at number of files in a directory, non-recursive make doesn't have such a limitation 3) Removal of duplicate information in make files, less error prone I've also slightly updated how we call AM_INIT_AUTOMAKE, as the way that was used was not only deprecated but will be *removed* in the next major automake release (1.13).... so probably best that we can continue to bulid tor without requiring old automake. (see http://www.gnu.org/software/automake/manual/html_node/Public-Macros.html ) For more reasons why, see resources such as: http://miller.emu.id.au/pmiller/books/rmch/
2012-08-02 15:31:43 +02:00
Start work on fancy compiler tricks to expose extra stuff to our tests 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.
2013-06-06 20:56:05 +02:00
noinst_LIBRARIES += \
src/common/libor.a \
src/common/libor-crypto.a \
src/common/libor-event.a
if UNITTESTS_ENABLED
noinst_LIBRARIES += \
src/common/libor-testing.a \
src/common/libor-crypto-testing.a \
src/common/libor-event-testing.a
endif
Move to non-recursive make This gives us a few benefits: 1) make -j clean all this will start working, as it should. It currently doesn't. 2) increased parallel build recursive make will max out at number of files in a directory, non-recursive make doesn't have such a limitation 3) Removal of duplicate information in make files, less error prone I've also slightly updated how we call AM_INIT_AUTOMAKE, as the way that was used was not only deprecated but will be *removed* in the next major automake release (1.13).... so probably best that we can continue to bulid tor without requiring old automake. (see http://www.gnu.org/software/automake/manual/html_node/Public-Macros.html ) For more reasons why, see resources such as: http://miller.emu.id.au/pmiller/books/rmch/
2012-08-02 15:31:43 +02:00
EXTRA_DIST+= \
src/common/common_sha1.i \
src/common/Makefile.nmake
#CFLAGS = -Wall -Wpointer-arith -O2
Use trunnel for crypto_pwbox encoding/decoding. This reduces the likelihood that I have made any exploitable errors in the encoding/decoding. This commit also imports the trunnel runtime source into Tor.
2014-09-24 16:51:39 +02:00
AM_CPPFLAGS += -I$(srcdir)/src/common -Isrc/common -I$(srcdir)/src/ext/trunnel -I$(srcdir)/src/trunnel
Move to non-recursive make This gives us a few benefits: 1) make -j clean all this will start working, as it should. It currently doesn't. 2) increased parallel build recursive make will max out at number of files in a directory, non-recursive make doesn't have such a limitation 3) Removal of duplicate information in make files, less error prone I've also slightly updated how we call AM_INIT_AUTOMAKE, as the way that was used was not only deprecated but will be *removed* in the next major automake release (1.13).... so probably best that we can continue to bulid tor without requiring old automake. (see http://www.gnu.org/software/automake/manual/html_node/Public-Macros.html ) For more reasons why, see resources such as: http://miller.emu.id.au/pmiller/books/rmch/
2012-08-02 15:31:43 +02:00
if USE_OPENBSD_MALLOC
Move all externally maintained source files into src/ext The rationale for treating these files differently is that we should be checking upstream for changes as applicable, and merging changes upstream as warranted.
2012-10-11 23:19:37 +02:00
libor_extra_source=src/ext/OpenBSD_malloc_Linux.c
Move to non-recursive make This gives us a few benefits: 1) make -j clean all this will start working, as it should. It currently doesn't. 2) increased parallel build recursive make will max out at number of files in a directory, non-recursive make doesn't have such a limitation 3) Removal of duplicate information in make files, less error prone I've also slightly updated how we call AM_INIT_AUTOMAKE, as the way that was used was not only deprecated but will be *removed* in the next major automake release (1.13).... so probably best that we can continue to bulid tor without requiring old automake. (see http://www.gnu.org/software/automake/manual/html_node/Public-Macros.html ) For more reasons why, see resources such as: http://miller.emu.id.au/pmiller/books/rmch/
2012-08-02 15:31:43 +02:00
else
libor_extra_source=
endif
Add --disable-mempools configure option
2014-05-13 03:23:34 +02:00
if USE_MEMPOOLS
libor_mempool_source=src/common/mempool.c
libor_mempool_header=src/common/mempool.h
else
libor_mempool_source=
libor_mempool_header=
endif
Build donna32 with -fomit-frame-pointer
2013-01-30 19:08:04 +01:00
src_common_libcurve25519_donna_a_CFLAGS=
Add a wrapper around, and test and build support for, curve25519. 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.
2012-12-03 21:44:21 +01:00
if BUILD_CURVE25519_DONNA
Make libcurve25519_donna get built as a .a This lets us give it compiler flags differing from the rest of libor-crypto.a
2012-12-06 18:07:58 +01:00
src_common_libcurve25519_donna_a_SOURCES=\
src/ext/curve25519_donna/curve25519-donna.c
Build donna32 with -fomit-frame-pointer
2013-01-30 19:08:04 +01:00
src_common_libcurve25519_donna_a_CFLAGS+=\
@F_OMIT_FRAME_POINTER@
Make libcurve25519_donna get built as a .a This lets us give it compiler flags differing from the rest of libor-crypto.a
2012-12-06 18:07:58 +01:00
noinst_LIBRARIES+=src/common/libcurve25519_donna.a
LIBDONNA=src/common/libcurve25519_donna.a
Add a wrapper around, and test and build support for, curve25519. 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.
2012-12-03 21:44:21 +01:00
else
if BUILD_CURVE25519_DONNA_C64
Make libcurve25519_donna get built as a .a This lets us give it compiler flags differing from the rest of libor-crypto.a
2012-12-06 18:07:58 +01:00
src_common_libcurve25519_donna_a_SOURCES=\
src/ext/curve25519_donna/curve25519-donna-c64.c
noinst_LIBRARIES+=src/common/libcurve25519_donna.a
LIBDONNA=src/common/libcurve25519_donna.a
Add a wrapper around, and test and build support for, curve25519. 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.
2012-12-03 21:44:21 +01:00
else
Make libcurve25519_donna get built as a .a This lets us give it compiler flags differing from the rest of libor-crypto.a
2012-12-06 18:07:58 +01:00
LIBDONNA=
Add a wrapper around, and test and build support for, curve25519. 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.
2012-12-03 21:44:21 +01:00
endif
endif
Make libcurve25519_donna get built as a .a This lets us give it compiler flags differing from the rest of libor-crypto.a
2012-12-06 18:07:58 +01:00
Add Ed25519 support, wrappers, and tests. Taken from earlier ed25519 branch based on floodyberry's ed25519-donna. Tweaked so that it applies to ref10 instead.
2013-09-29 19:30:24 +02:00
LIBDONNA += $(LIBED25519_REF10)
Start work on fancy compiler tricks to expose extra stuff to our tests 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.
2013-06-06 20:56:05 +02:00
LIBOR_A_SOURCES = \
Move to non-recursive make This gives us a few benefits: 1) make -j clean all this will start working, as it should. It currently doesn't. 2) increased parallel build recursive make will max out at number of files in a directory, non-recursive make doesn't have such a limitation 3) Removal of duplicate information in make files, less error prone I've also slightly updated how we call AM_INIT_AUTOMAKE, as the way that was used was not only deprecated but will be *removed* in the next major automake release (1.13).... so probably best that we can continue to bulid tor without requiring old automake. (see http://www.gnu.org/software/automake/manual/html_node/Public-Macros.html ) For more reasons why, see resources such as: http://miller.emu.id.au/pmiller/books/rmch/
2012-08-02 15:31:43 +02:00
src/common/address.c \
Basic backtrace ability 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.
2013-07-19 20:09:58 +02:00
src/common/backtrace.c \
Move to non-recursive make This gives us a few benefits: 1) make -j clean all this will start working, as it should. It currently doesn't. 2) increased parallel build recursive make will max out at number of files in a directory, non-recursive make doesn't have such a limitation 3) Removal of duplicate information in make files, less error prone I've also slightly updated how we call AM_INIT_AUTOMAKE, as the way that was used was not only deprecated but will be *removed* in the next major automake release (1.13).... so probably best that we can continue to bulid tor without requiring old automake. (see http://www.gnu.org/software/automake/manual/html_node/Public-Macros.html ) For more reasons why, see resources such as: http://miller.emu.id.au/pmiller/books/rmch/
2012-08-02 15:31:43 +02:00
src/common/compat.c \
src/common/container.c \
src/common/di_ops.c \
src/common/log.c \
src/common/memarea.c \
src/common/util.c \
src/common/util_codedigest.c \
New waitpid-handler functions to run callbacks when a child exits. Also, move 'procmon' into libor_event library, since it uses libevent.
2014-04-09 19:45:27 +02:00
src/common/util_process.c \
cosmetic cleanups
2013-07-14 08:49:34 +02:00
src/common/sandbox.c \
Get csiphash better integrated with our build system
2014-02-12 16:24:04 +01:00
src/ext/csiphash.c \
Use trunnel for crypto_pwbox encoding/decoding. This reduces the likelihood that I have made any exploitable errors in the encoding/decoding. This commit also imports the trunnel runtime source into Tor.
2014-09-24 16:51:39 +02:00
src/ext/trunnel/trunnel.c \
Add --disable-mempools configure option
2014-05-13 03:23:34 +02:00
$(libor_extra_source) \
$(libor_mempool_source)
Move to non-recursive make This gives us a few benefits: 1) make -j clean all this will start working, as it should. It currently doesn't. 2) increased parallel build recursive make will max out at number of files in a directory, non-recursive make doesn't have such a limitation 3) Removal of duplicate information in make files, less error prone I've also slightly updated how we call AM_INIT_AUTOMAKE, as the way that was used was not only deprecated but will be *removed* in the next major automake release (1.13).... so probably best that we can continue to bulid tor without requiring old automake. (see http://www.gnu.org/software/automake/manual/html_node/Public-Macros.html ) For more reasons why, see resources such as: http://miller.emu.id.au/pmiller/books/rmch/
2012-08-02 15:31:43 +02:00
Start work on fancy compiler tricks to expose extra stuff to our tests 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.
2013-06-06 20:56:05 +02:00
LIBOR_CRYPTO_A_SOURCES = \
Move to non-recursive make This gives us a few benefits: 1) make -j clean all this will start working, as it should. It currently doesn't. 2) increased parallel build recursive make will max out at number of files in a directory, non-recursive make doesn't have such a limitation 3) Removal of duplicate information in make files, less error prone I've also slightly updated how we call AM_INIT_AUTOMAKE, as the way that was used was not only deprecated but will be *removed* in the next major automake release (1.13).... so probably best that we can continue to bulid tor without requiring old automake. (see http://www.gnu.org/software/automake/manual/html_node/Public-Macros.html ) For more reasons why, see resources such as: http://miller.emu.id.au/pmiller/books/rmch/
2012-08-02 15:31:43 +02:00
src/common/aes.c \
src/common/crypto.c \
Rudimentary-but-sufficient passphrase-encrypted box code. See crypto_pwbox.c for a description of the file format. There are tests for successful operation, but it still needs error-case tests.
2014-08-28 23:59:06 +02:00
src/common/crypto_pwbox.c \
Move secret-to-key functionality into a separate module I'm about to add more of these, so we might as well trudge forward.
2014-08-28 18:04:22 +02:00
src/common/crypto_s2k.c \
Fix compilation with --disable-curve25519 option The fix is to move the two functions to format/parse base64 curve25519 public keys into a new "crypto_format.c" file. I could have put them in crypto.c, but that's a big file worth splitting anyway. Fixes bug 8153; bugfix on 0.2.4.8-alpha where I did the fix for 7869.
2013-02-04 17:32:55 +01:00
src/common/crypto_format.c \
Move to non-recursive make This gives us a few benefits: 1) make -j clean all this will start working, as it should. It currently doesn't. 2) increased parallel build recursive make will max out at number of files in a directory, non-recursive make doesn't have such a limitation 3) Removal of duplicate information in make files, less error prone I've also slightly updated how we call AM_INIT_AUTOMAKE, as the way that was used was not only deprecated but will be *removed* in the next major automake release (1.13).... so probably best that we can continue to bulid tor without requiring old automake. (see http://www.gnu.org/software/automake/manual/html_node/Public-Macros.html ) For more reasons why, see resources such as: http://miller.emu.id.au/pmiller/books/rmch/
2012-08-02 15:31:43 +02:00
src/common/torgzip.c \
Add a wrapper around, and test and build support for, curve25519. 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.
2012-12-03 21:44:21 +01:00
src/common/tortls.c \
Remove configure option to disable curve25519 By now, support in the network is widespread and it's time to require more modern crypto on all Tor instances, whether they're clients or servers. By doing this early in 0.2.6, we can be sure that at some point all clients will have reasonable support.
2014-10-27 14:37:50 +01:00
src/trunnel/pwbox.c \
src/common/crypto_curve25519.c \
src/common/crypto_ed25519.c
Move to non-recursive make This gives us a few benefits: 1) make -j clean all this will start working, as it should. It currently doesn't. 2) increased parallel build recursive make will max out at number of files in a directory, non-recursive make doesn't have such a limitation 3) Removal of duplicate information in make files, less error prone I've also slightly updated how we call AM_INIT_AUTOMAKE, as the way that was used was not only deprecated but will be *removed* in the next major automake release (1.13).... so probably best that we can continue to bulid tor without requiring old automake. (see http://www.gnu.org/software/automake/manual/html_node/Public-Macros.html ) For more reasons why, see resources such as: http://miller.emu.id.au/pmiller/books/rmch/
2012-08-02 15:31:43 +02:00
New waitpid-handler functions to run callbacks when a child exits. Also, move 'procmon' into libor_event library, since it uses libevent.
2014-04-09 19:45:27 +02:00
LIBOR_EVENT_A_SOURCES = \
src/common/compat_libevent.c \
src/common/procmon.c
Start work on fancy compiler tricks to expose extra stuff to our tests 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.
2013-06-06 20:56:05 +02:00
src_common_libor_a_SOURCES = $(LIBOR_A_SOURCES)
src_common_libor_crypto_a_SOURCES = $(LIBOR_CRYPTO_A_SOURCES)
src_common_libor_event_a_SOURCES = $(LIBOR_EVENT_A_SOURCES)
src_common_libor_testing_a_SOURCES = $(LIBOR_A_SOURCES)
src_common_libor_crypto_testing_a_SOURCES = $(LIBOR_CRYPTO_A_SOURCES)
src_common_libor_event_testing_a_SOURCES = $(LIBOR_EVENT_A_SOURCES)
src_common_libor_testing_a_CPPFLAGS = -DTOR_UNIT_TESTS $(AM_CPPFLAGS)
src_common_libor_crypto_testing_a_CPPFLAGS = -DTOR_UNIT_TESTS $(AM_CPPFLAGS)
src_common_libor_event_testing_a_CPPFLAGS = -DTOR_UNIT_TESTS $(AM_CPPFLAGS)
Coverage support: build with --enable-coverage to have tests run with gcov 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.
2013-07-09 18:37:11 +02:00
src_common_libor_testing_a_CFLAGS = $(AM_CFLAGS) $(TEST_CFLAGS)
src_common_libor_crypto_testing_a_CFLAGS = $(AM_CFLAGS) $(TEST_CFLAGS)
src_common_libor_event_testing_a_CFLAGS = $(AM_CFLAGS) $(TEST_CFLAGS)
Move to non-recursive make This gives us a few benefits: 1) make -j clean all this will start working, as it should. It currently doesn't. 2) increased parallel build recursive make will max out at number of files in a directory, non-recursive make doesn't have such a limitation 3) Removal of duplicate information in make files, less error prone I've also slightly updated how we call AM_INIT_AUTOMAKE, as the way that was used was not only deprecated but will be *removed* in the next major automake release (1.13).... so probably best that we can continue to bulid tor without requiring old automake. (see http://www.gnu.org/software/automake/manual/html_node/Public-Macros.html ) For more reasons why, see resources such as: http://miller.emu.id.au/pmiller/books/rmch/
2012-08-02 15:31:43 +02:00
Fix a build-warning when building out-of-tree We were trying to incorporate all headers in common_sha1.i, not just the src/common ones. This is part of bug 6778; fix on 0.2.4.1-alpha
2012-09-06 15:56:48 +02:00
COMMONHEADERS = \
Move to non-recursive make This gives us a few benefits: 1) make -j clean all this will start working, as it should. It currently doesn't. 2) increased parallel build recursive make will max out at number of files in a directory, non-recursive make doesn't have such a limitation 3) Removal of duplicate information in make files, less error prone I've also slightly updated how we call AM_INIT_AUTOMAKE, as the way that was used was not only deprecated but will be *removed* in the next major automake release (1.13).... so probably best that we can continue to bulid tor without requiring old automake. (see http://www.gnu.org/software/automake/manual/html_node/Public-Macros.html ) For more reasons why, see resources such as: http://miller.emu.id.au/pmiller/books/rmch/
2012-08-02 15:31:43 +02:00
src/common/address.h \
Basic backtrace ability 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.
2013-07-19 20:09:58 +02:00
src/common/backtrace.h \
Move to non-recursive make This gives us a few benefits: 1) make -j clean all this will start working, as it should. It currently doesn't. 2) increased parallel build recursive make will max out at number of files in a directory, non-recursive make doesn't have such a limitation 3) Removal of duplicate information in make files, less error prone I've also slightly updated how we call AM_INIT_AUTOMAKE, as the way that was used was not only deprecated but will be *removed* in the next major automake release (1.13).... so probably best that we can continue to bulid tor without requiring old automake. (see http://www.gnu.org/software/automake/manual/html_node/Public-Macros.html ) For more reasons why, see resources such as: http://miller.emu.id.au/pmiller/books/rmch/
2012-08-02 15:31:43 +02:00
src/common/aes.h \
src/common/ciphers.inc \
src/common/compat.h \
src/common/compat_libevent.h \
src/common/container.h \
src/common/crypto.h \
Add a wrapper around, and test and build support for, curve25519. 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.
2012-12-03 21:44:21 +01:00
src/common/crypto_curve25519.h \
Add Ed25519 support, wrappers, and tests. Taken from earlier ed25519 branch based on floodyberry's ed25519-donna. Tweaked so that it applies to ref10 instead.
2013-09-29 19:30:24 +02:00
src/common/crypto_ed25519.h \
Rudimentary-but-sufficient passphrase-encrypted box code. See crypto_pwbox.c for a description of the file format. There are tests for successful operation, but it still needs error-case tests.
2014-08-28 23:59:06 +02:00
src/common/crypto_pwbox.h \
More generic passphrase hashing code, including scrypt support 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.
2014-08-28 23:38:22 +02:00
src/common/crypto_s2k.h \
Move to non-recursive make This gives us a few benefits: 1) make -j clean all this will start working, as it should. It currently doesn't. 2) increased parallel build recursive make will max out at number of files in a directory, non-recursive make doesn't have such a limitation 3) Removal of duplicate information in make files, less error prone I've also slightly updated how we call AM_INIT_AUTOMAKE, as the way that was used was not only deprecated but will be *removed* in the next major automake release (1.13).... so probably best that we can continue to bulid tor without requiring old automake. (see http://www.gnu.org/software/automake/manual/html_node/Public-Macros.html ) For more reasons why, see resources such as: http://miller.emu.id.au/pmiller/books/rmch/
2012-08-02 15:31:43 +02:00
src/common/di_ops.h \
src/common/memarea.h \
Log the name of the failing syscall on failure
2014-04-17 04:22:47 +02:00
src/common/linux_syscalls.inc \
Move to non-recursive make This gives us a few benefits: 1) make -j clean all this will start working, as it should. It currently doesn't. 2) increased parallel build recursive make will max out at number of files in a directory, non-recursive make doesn't have such a limitation 3) Removal of duplicate information in make files, less error prone I've also slightly updated how we call AM_INIT_AUTOMAKE, as the way that was used was not only deprecated but will be *removed* in the next major automake release (1.13).... so probably best that we can continue to bulid tor without requiring old automake. (see http://www.gnu.org/software/automake/manual/html_node/Public-Macros.html ) For more reasons why, see resources such as: http://miller.emu.id.au/pmiller/books/rmch/
2012-08-02 15:31:43 +02:00
src/common/procmon.h \
put sandbox.h in the tarball, so the tarball builds
2013-07-14 02:31:18 +02:00
src/common/sandbox.h \
Start work on fancy compiler tricks to expose extra stuff to our tests 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.
2013-06-06 20:56:05 +02:00
src/common/testsupport.h \
Move to non-recursive make This gives us a few benefits: 1) make -j clean all this will start working, as it should. It currently doesn't. 2) increased parallel build recursive make will max out at number of files in a directory, non-recursive make doesn't have such a limitation 3) Removal of duplicate information in make files, less error prone I've also slightly updated how we call AM_INIT_AUTOMAKE, as the way that was used was not only deprecated but will be *removed* in the next major automake release (1.13).... so probably best that we can continue to bulid tor without requiring old automake. (see http://www.gnu.org/software/automake/manual/html_node/Public-Macros.html ) For more reasons why, see resources such as: http://miller.emu.id.au/pmiller/books/rmch/
2012-08-02 15:31:43 +02:00
src/common/torgzip.h \
src/common/torint.h \
src/common/torlog.h \
src/common/tortls.h \
Add --disable-mempools configure option
2014-05-13 03:23:34 +02:00
src/common/util.h \
Merge branch 'bug8746_v2_squashed' Conflicts: src/common/include.am
2014-06-14 17:46:38 +02:00
src/common/util_process.h \
Add --disable-mempools configure option
2014-05-13 03:23:34 +02:00
$(libor_mempool_header)
Move to non-recursive make This gives us a few benefits: 1) make -j clean all this will start working, as it should. It currently doesn't. 2) increased parallel build recursive make will max out at number of files in a directory, non-recursive make doesn't have such a limitation 3) Removal of duplicate information in make files, less error prone I've also slightly updated how we call AM_INIT_AUTOMAKE, as the way that was used was not only deprecated but will be *removed* in the next major automake release (1.13).... so probably best that we can continue to bulid tor without requiring old automake. (see http://www.gnu.org/software/automake/manual/html_node/Public-Macros.html ) For more reasons why, see resources such as: http://miller.emu.id.au/pmiller/books/rmch/
2012-08-02 15:31:43 +02:00
Fix a build-warning when building out-of-tree We were trying to incorporate all headers in common_sha1.i, not just the src/common ones. This is part of bug 6778; fix on 0.2.4.1-alpha
2012-09-06 15:56:48 +02:00
noinst_HEADERS+= $(COMMONHEADERS)
Fix up make distcheck and greatly simplify docs dependencies (although it's still a bit odd)
2012-08-03 03:20:52 +02:00
DISTCLEANFILES+= src/common/common_sha1.i
Fix a build-warning when building out-of-tree We were trying to incorporate all headers in common_sha1.i, not just the src/common ones. This is part of bug 6778; fix on 0.2.4.1-alpha
2012-09-06 15:56:48 +02:00
src/common/common_sha1.i: $(libor_SOURCES) $(libor_crypto_a_SOURCES) $(COMMONHEADERS)
Make the _sha1.i file generation quieter
2012-08-23 19:14:41 +02:00
$(AM_V_GEN)if test "@SHA1SUM@" != none; then \
Fix a build-warning when building out-of-tree We were trying to incorporate all headers in common_sha1.i, not just the src/common ones. This is part of bug 6778; fix on 0.2.4.1-alpha
2012-09-06 15:56:48 +02:00
(cd "$(srcdir)" && "@SHA1SUM@" $(src_common_libor_SOURCES) $(src_common_libor_crypto_a_SOURCES) $(COMMONHEADERS)) | "@SED@" -n 's/^\(.*\)$$/"\1\\n"/p' > $@; \
Move to non-recursive make This gives us a few benefits: 1) make -j clean all this will start working, as it should. It currently doesn't. 2) increased parallel build recursive make will max out at number of files in a directory, non-recursive make doesn't have such a limitation 3) Removal of duplicate information in make files, less error prone I've also slightly updated how we call AM_INIT_AUTOMAKE, as the way that was used was not only deprecated but will be *removed* in the next major automake release (1.13).... so probably best that we can continue to bulid tor without requiring old automake. (see http://www.gnu.org/software/automake/manual/html_node/Public-Macros.html ) For more reasons why, see resources such as: http://miller.emu.id.au/pmiller/books/rmch/
2012-08-02 15:31:43 +02:00
elif test "@OPENSSL@" != none; then \
Fix a build-warning when building out-of-tree We were trying to incorporate all headers in common_sha1.i, not just the src/common ones. This is part of bug 6778; fix on 0.2.4.1-alpha
2012-09-06 15:56:48 +02:00
(cd "$(srcdir)" && "@OPENSSL@" sha1 $(src_common_libor_SOURCES) $(src_Common_libor_crypto_a_SOURCES) $(COMMONHEADERS)) | "@SED@" -n 's/SHA1(\(.*\))= \(.*\)/"\2 \1\\n"/p' > $@; \
Move to non-recursive make This gives us a few benefits: 1) make -j clean all this will start working, as it should. It currently doesn't. 2) increased parallel build recursive make will max out at number of files in a directory, non-recursive make doesn't have such a limitation 3) Removal of duplicate information in make files, less error prone I've also slightly updated how we call AM_INIT_AUTOMAKE, as the way that was used was not only deprecated but will be *removed* in the next major automake release (1.13).... so probably best that we can continue to bulid tor without requiring old automake. (see http://www.gnu.org/software/automake/manual/html_node/Public-Macros.html ) For more reasons why, see resources such as: http://miller.emu.id.au/pmiller/books/rmch/
2012-08-02 15:31:43 +02:00
else \
Fix up make distcheck and greatly simplify docs dependencies (although it's still a bit odd)
2012-08-03 03:20:52 +02:00
rm $@; \
touch $@; \
Move to non-recursive make This gives us a few benefits: 1) make -j clean all this will start working, as it should. It currently doesn't. 2) increased parallel build recursive make will max out at number of files in a directory, non-recursive make doesn't have such a limitation 3) Removal of duplicate information in make files, less error prone I've also slightly updated how we call AM_INIT_AUTOMAKE, as the way that was used was not only deprecated but will be *removed* in the next major automake release (1.13).... so probably best that we can continue to bulid tor without requiring old automake. (see http://www.gnu.org/software/automake/manual/html_node/Public-Macros.html ) For more reasons why, see resources such as: http://miller.emu.id.au/pmiller/books/rmch/
2012-08-02 15:31:43 +02:00
fi
Fix up make distcheck and greatly simplify docs dependencies (although it's still a bit odd)
2012-08-03 03:20:52 +02:00
src/common/util_codedigest.o: src/common/common_sha1.i
Drop support for openssl 0.9.7 097 hasn't seen a new version since 2007; we can drop support too. This lets us remove our built-in sha256 implementation, and some checks for old bugs.
2012-09-13 01:25:58 +02:00
Reference in New Issue Copy Permalink