| Age | Commit message (Collapse) | Author |
|---|
|
The Automake variable OBJEXT is automatically adjusted to the correct
object file extension for the target platform.
|
|
Fixes make -j for some users; fixes bug 17826.
Bugfix on 0.2.5.1, when we started building testing versions of all
the object files.
|
|
|
|
The base64 and base32 functions used to be in crypto.c;
crypto_format.h had no header; some general-purpose functions were in
crypto_curve25519.c.
This patch makes a {crypto,util}_format.[ch], and puts more functions
there. Small modules are beautiful!
|
|
Integrate ed25519-donna into the build process, and provide an
interface that matches the `ref10` code. Apart from the blinding and
Curve25519 key conversion, this functions as a drop-in replacement for
ref10 (verified by modifying crypto_ed25519.c).
Tests pass, and the benchmarks claim it is quite a bit faster, however
actually using the code requires additional integration work.
|
|
This way glibc users don't have to fall back to getpass.
Windows users are still out of luck
|
|
This is a fair amount of maintainance burden, and doesn't help much
more than the git microversion.
Closes ticket 14742.
|
|
This removes roughly 5000 branches in my testing. We never want to
trigger assertions even during tests, so this is sane. Implements #15400.
|
|
|
|
Otherwise micro-revision.i might not get built on time.
|
|
These files get generated automatically so there is need to include them in the
distribution.
|
|
Remove src/or/or_sha1.i and src/common/common_sha1.i on `make clean` and remove
the temporary micro-revision file when its no longer needed.
Additional changes;
- show a message when generating the micro-revision file.
- add the temporary micro revision file to the list of files to be removed on
`make clean` just in case.
- fix indentation of the make rule to improve readability.
|
|
This reverts commit 930ab95e1fb0dfd5af35e7d84ca58ff21b65a605.
|
|
|
|
|
|
They have been off-by-default since 0.2.5 and nobody has complained. :)
Also remove the buf_shrink() function, which hasn't done anything
since we first stopped using contiguous memory to store buffers.
Closes ticket 14848.
|
|
It seems to be working, but more tuning is needed.
|
|
Also, re-enable the #if'd out condition-variable code.
Work queues are going to make us hack on all of this stuff a bit more
closely, so it might not be a terrible idea to make it easier to hack.
|
|
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.
|
|
Conflicts:
src/common/include.am
src/ext/README
|
|
Taken from earlier ed25519 branch based on floodyberry's
ed25519-donna. Tweaked so that it applies to ref10 instead.
|
|
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.
|
|
See crypto_pwbox.c for a description of the file format.
There are tests for successful operation, but it still needs
error-case tests.
|
|
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.
|
|
I'm about to add more of these, so we might as well trudge forward.
|
|
Conflicts:
src/common/include.am
|
|
Also, move 'procmon' into libor_event library, since it uses libevent.
|
|
|
|
|
|
|
|
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.
|
|
Conflicts:
src/common/include.am
Conflict was from adding testsupport.h near where sandbox.h had
already been added.
|
|
|
|
|
|
It's controlled by the new Sandbox argument. Right now, it's rather
coarse-grained, it's Linux-only, and it may break some features.
|
|
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.
|
|
|
|
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.
|
|
|
|
This lets us give it compiler flags differing from the rest of
libor-crypto.a
|
|
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.
|
|
|
|
The rationale for treating these files differently is that we should
be checking upstream for changes as applicable, and merging changes
upstream as warranted.
|
|
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.
|
|
|
|
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
|
|
|
|
|
|
still a bit odd)
|
