| Age | Commit message (Collapse) | Author |
|---|
|
- make tor_util static library name configurable
- fix Rust libary dependency order for Windows
|
|
Introduce a way to optionally enable Rust integration for our builds. No
actual Rust code is added yet and specifying the flag has no effect
other than failing the build if rustc and cargo are unavailable.
|
|
CVE-2008-0166 is long gone, and we no longer need a helper tool to
dump out public key moduli so folks can detect it.
Closes ticket 21842.
|
|
|
|
If a hostname is supplied to tor-resolve which is too long, it will be
silently truncated, resulting in a different hostname lookup:
$ tor-resolve $(python -c 'print("google.com" + "m" * 256)')
If tor-resolve uses SOCKS5, the length is stored in an unsigned char,
which overflows in this case and leads to the hostname "google.com".
As this one is a valid hostname, it returns an address instead of giving
an error due to the invalid supplied hostname.
|
|
They broke stem, and breaking application compatibility is usually a
bad idea.
This reverts commit 6e10130e18c80f4521e31b071455ae0b1bbea761,
commit 78a13df15842e8ab262e17825160386fadb77056, and
commit 62f52a888acc191bcb507d27d31d54e42e6effdd.
We might re-apply this later, if all the downstream tools can handle
it, and it turns out to be useful for some reason.
|
|
|
|
|
|
|
|
In our code to write public keys to a string, for some unfathomable
reason since 253f0f160e1185c, we would allocate a memory BIO, then
set the NOCLOSE flag on it, extract its memory buffer, and free it.
Then a little while later we'd free the memory buffer with
BUF_MEM_free().
As of openssl 1.1 this doesn't work any more, since there is now a
BIO_BUF_MEM structure that wraps the BUF_MEM structure. This
BIO_BUF_MEM doesn't get freed in our code.
So, we had a memory leak!
Is this an openssl bug? Maybe. But our code was already pretty
silly. Why mess around with the NOCLOSE flag here when we can just
keep the BIO object around until we don't need the buffer any more?
Fixes bug 20553; bugfix on 0.0.2pre8
|
|
|
|
The previous version of the new accessors didn't specify const but it
was changed in master.
|
|
|
|
|
|
|
|
There's accessors to get at things, but it ends up being rather
cumbersome. The only place where behavior should change is that the
code will fail instead of attempting to generate a new DH key if our
internal sanity check fails.
Like the previous commit, this probably breaks snapshots prior to pre5.
|
|
This is a big-ish patch, but it's very straightforward. Under this
clang warning, we're not actually allowed to have a global variable
without a previous extern declaration for it. The cases where we
violated this rule fall into three roughly equal groups:
* Stuff that should have been static.
* Stuff that was global but where the extern was local to some
other C file.
* Stuff that was only global when built for the unit tests, that
needed a conditional extern in the headers.
The first two were IMO genuine problems; the last is a wart of how
we build tests.
|
|
This is a whitespace only, cosmetic fix.
There is still some inconsistency between lists, but less
inconsistency inside individual lists.
|
|
There were some conflicts here, and some breakage to fix concerning
library link order in newer targets.
|
|
We know there are overflows in curve25519-donna-c32, so we'll have
to have that one be fwrapv.
Only apply the asan, ubsan, and trapv options to the code that does
not need to run in constant time. Those options introduce branches
to the code they instrument.
(These introduced branches should never actually be taken, so it
might _still_ be constant time after all, but branch predictors are
complicated enough that I'm not really confident here. Let's aim for
safety.)
Closes 17983.
|
|
This way I can run chutney under asan.
Fixes part of 18672.
|
|
Closes ticket 17443.
|
|
* DIGEST_SHA3_[256,512] added as supported algorithms, which do
exactly what is said on the tin.
* test/bench now benchmarks all of the supported digest algorithms,
so it's possible to see just how slow SHA-3 is, though the message
sizes could probably use tweaking since this is very dependent on
the message size vs the SHA-3 rate.
|
|
|
|
|
|
|
|
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!
|
|
It did a good idea, but the code-quality of libupnpc and libnatpnp
is so dodgy that I'm not really comfortable including them alongside
Tor proper. Instead, we'll recommend that people do the pure-go
reimplementation instead. Closes ticket 13338.
|
|
|
|
Conflicts:
src/test/testing_common.c
|
|
It needed an argument before because it wasn't safe to call
RAND_poll() on openssl 0.9.8c if you had already opened more fds
than would fit in fd_set.
|
|
|
|
|
|
This allows us to run tor-cov-gencert from chutney for coverage builds.
|
|
The paths are already in the directory search path of the compiler therefore no
need to include them in the source code.
|
|
Resolves 14325
|
|
|
|
Because in 95 years, we or our successors will surely care about
enforcing the BSD license terms on this code. Right?
|
|
Conflicts:
src/tools/tor-resolve.c
|
|
|
|
Fixes bug 13295; bugfix on 0.2.5.3-alpha.
The alternative here is to call crypto_global_init() from tor-resolve,
but let's avoid linking openssl into tor-resolve for as long as we
can.
|
|
(And replay them once we know our first real logs.)
This is an implementation for issue 6938. It solves the problem of
early log mesages not getting sent to log files, but not the issue of
early log messages not getting sent to controllers.
|
|
Found by coverity, which noticed that if you said
tor-gencert -i identity1 -i identity2
we would leak "identity1".
[CID 1198201, 1198202, 1198203]
|
|
This is harmless, since tor-gencert exits right afterwards, but it's
best to clean up after ourselves.
|
|
|
|
We need this now that tor-fw-helper will pull in siphash.h
Fixes bug 11296; bugfix on 0.2.5.4-alpha where siphash.h was introduced.
|
|
|
|
We previously used FILENAME_PRIVATE identifiers mostly for
identifiers exposed only to the unit tests... but also for
identifiers exposed to the benchmarker, and sometimes for
identifiers exposed to a similar module, and occasionally for no
really good reason at all.
Now, we use FILENAME_PRIVATE identifiers for identifiers shared by
Tor and the unit tests. They should be defined static when we
aren't building the unit test, and globally visible otherwise. (The
STATIC macro will keep us honest here.)
For identifiers used only by the unit tests and never by Tor at all,
on the other hand, we wrap them in #ifdef TOR_UNIT_TESTS.
This is not the motivating use case for the split test/non-test
build system; it's just a test example to see how it works, and to
take a chance to clean up the code a little.
|
|
It's returning the number of initialized backends.
(changes file added by nickm; this is a fix for bug #9030)
|
|
|
