Age | Commit message (Collapse) | Author |
|
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.
|
|
We didn't really have test coverage for these parsing functions, so
I went and made some. These tests also verify that the parsing
functions set the list of invalid digests correctly.
|
|
|
|
Patch from "chobe". Closes ticket 961.
|
|
Conflicts:
src/common/include.am
src/ext/README
|
|
Also, use it to generate test vectors, and add those test vectors
to test_crypto.c
This is based on ed25519.py from the ed25519 webpage; the kludgy hacks
are my own.
|
|
Conflicts:
src/test/test_crypto.c
|
|
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.
|
|
This is using the paradigm introduced for test_status.c.
|
|
Making the text file work out-of-tree didn't work on windows.
Maybe we can get it working that way later.
|
|
|
|
A new set of unit test cases are provided, as well as introducing
an alternative paradigm and macros to support it. Primarily, each test
case is given its own namespace, in order to isolate tests from each
other. We do this by in the usual fashion, by appending module and
submodule names to our symbols. New macros assist by reducing friction
for this and other tasks, like overriding a function in the global
namespace with one in the current namespace, or declaring integer
variables to assist tracking how many times a mock has been called.
A set of tests for a small-scale module has been included in this
commit, in order to highlight how the paradigm can be used. This
suite gives 100% coverage to status.c in test execution.
|
|
Conflicts:
src/test/include.am
src/test/test.c
|
|
|
|
Also rename a function to be more accurate (resolve->resolved)
|
|
Conflicts:
src/test/test.c
|
|
|
|
|
|
|
|
This function is not used anymore
|
|
'make distcheck' now passes again.
|
|
|
|
|
|
Conflicts:
src/common/sandbox.c
src/common/sandbox.h
src/common/util.c
src/or/main.c
src/test/include.am
src/test/test.c
|
|
These need to be a separate executable, since the point of backtrace.c
is that it can crash and write stuff.
|
|
|
|
Conflicts:
doc/tor.1.txt
src/or/config.c
src/or/connection.h
src/or/control.c
src/or/control.h
src/or/or.h
src/or/relay.c
src/or/relay.h
src/test/test.c
|
|
|
|
|
|
|
|
I broke this when I added separate test-mode support by having
the benchmarks get built with TEST_CFLAGS.
|
|
|
|
|
|
No other changes were made here. Keeping everything in
src/test/test.c was a legacy of back when we had all our unit tests in
one big file.
Doing this now because I'm adding an ext_or_command test.
|
|
This exercises the code that crashed and caused #9296.
|
|
I added this so I could write a unit test for ServerTransportOptions,
but it incidentally exercises the succeed-on-defaults case of
options_validate too.
|
|
This removes some INLINE markers from functions that probably didn't
need them.
|
|
These show off the new mocking code by mocking the circuitmux code
so that we can test the circuit map code in isolation.
|
|
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.
|
|
tor_tls_evp_pkey_eq
|
|
|
|
|
|
Fixes more of bug 7972
|
|
Before I started coding ntor in C, I did another one in Python.
Turns out, they interoperate just fine.
|
|
This lets us give it compiler flags differing from the rest of
libor-crypto.a
|
|
Add 'flags' argument to begin cells, per proposal 208.
|
|
The rationale for treating these files differently is that we should
be checking upstream for changes as applicable, and merging changes
upstream as warranted.
|
|
|
|
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/
|