The Autoconf macro AC_USE_SYSTEM_EXTENSIONS defines preprocessor macros
which turn on extensions to C and POSIX. The macro also makes it easier
for developers to use the extensions without needing (or forgetting) to
define them manually.
The macro can be safely used because it was introduced in Autoconf 2.60
and Tor requires Autoconf 2.63 and above.
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 warning triggers on silently promoting a float to a double. In
our code, it's just a sign that somebody used a float by mistake,
since we always prefer double.
This warning, IIUC, means that the compiler doesn't like it when it
sees a NULL check _after_ we've already dereferenced the
variable. In such cases, it considers itself free to eliminate the
NULL check.
There are a couple of tricky cases:
One was the case related to the fact that tor_addr_to_in6() can
return NULL if it gets a non-AF_INET6 address. The fix was to
create a variant which asserts on the address type, and never
returns NULL.
Remove support for "GET /tor/bytes.txt" DirPort request, and
"GETINFO dir-usage" controller request, which were only available
via a compile-time option in Tor anyway.
Feature was added in 0.2.2.1-alpha. Resolves ticket 19035.
Previously, if the header was present, we'd proceed even if the
function wasn't there.
Easy fix for bug 19161. A better fix would involve trying harder to
find libscrypt_scrypt.
We use a pretty specific pair of autoconf tests here to make sure
that we only add this code when:
a) a 64-bit signed multiply fails to link,
AND
b) the same 64-bit signed multiply DOES link correctly when
__mulodi4 is defined.
Closes ticket 19079.
Previously we'd only check whether the hardening options succeeded
at the compile step. Now we'll try to link with them too, and tell
the user in advance if something seems likely to go wrong.
Closes ticket 18895.
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 makes our compilation options checks in autoconf work better on
systems that already define _FORTIFY_SOURCE.
Fixes at least one case of bug 18841; bugfix on 0.2.3.17-beta. Patch
from "trudokal".
We added these a while ago, but they do no actual good, and
cause implicit declaration warnings in some situations. Rather than
just adding stdint.h, it's easier to remove the exit() calls
as redundant.
Fixes bug 18626; bugfix from "cypherpunks"
CentOS 6 is roughly the oldest thing we care about developers still
using, and it has autoconf 2.63 / automake 1.11. These are both
older than openssl 1.0.0, so anybody who can't upgrade past those
probably can't upgrade to a modern openssl either. And since only
people building from git or editing configure.ac/Makefile.am need to
use autotools, I'm not totally enthused about keeping support for
old ones anyway.
Closes ticket 17732.
Closes ticket 18242.
The rationale here is that I like having coverage on by default in my
own working directory, but I always want assertions turned on unless
I'm doing branch coverage specifically.
We've never actually tested this support, and we should probably assume
it's broken.
To the best of my knowledge, only OpenVMS has this, and even on
OpenVMS it's a compile-time option to disable it. And I don't think
we build on openvms anyway. (Everybody else seems to be working
around the 2038 problem by using a 64-bit time_t, which won't expire
for roughly 292 billion years.)
Closes ticket 18184.
Use environment variables instead. This repairs 'make distcheck',
which was running into trouble when it tried to chmod the generated
scripts.
Fixes 17148.
This allows builds on machines with a crippled openssl to fail early
during configure. Bugfix on 0.2.7.1-alpha, which introduced the
requirement for ECC support. Fixes bug 17109.
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.
If the OpenSSL team accepts my patch to add an
SSL_get_client_ciphers function, this patch will make Tor use it
when available, thereby working better with openssl 1.1.
For this to work bt_test.py now returns an exit code indicating success or
failure. Additionally, check-local and its specific dependencies are now
obsolete so they are removed.
The zero length keys test now requires the path to the Tor binary as the first
parameter to ensure the correct Tor binary is used without hard coding a path.
The wrapper script calls the zero length keys test for each test separately to
ensure the correct shell is used (as configured by autoconf). Another solution
would have been to place the tests into separate functions so multiple tests
could be run internally. This would have made a diff of considerable size and
frankly it is outside the scope of this fix.
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.
If --disable-systemd is given, $enable_systemd is set to "no", not "false".
As a result, if libsystemd is found, we still turn on systemd support even
if we explicitly disable it with --disable-system.
This way we can use the linux eventfd extension where available.
Using EVFILT_USER on the BSDs will be a teeny bit trickier, and will
require libevent hacking.
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.
There were following problems:
- configure.ac wrongly checked for defined HAVE_SYSTEMD; this
wasn't working, so the watchdog code was not compiled in.
Replace library search with explicit version check
- sd_notify() watchdog call was unsetting NOTIFY_SOCKET from env;
this means only first "watchdog ping" was delivered, each
subsequent one did not have socket to be sent to and systemd
was killing service
- after those fixes, enable Watchdog in systemd unit with one
minute intervals
When I applied patch fcc78e5f8a, I somehow broke
stack trace symbols on Linux. I'll leave it to others to figure out
why that happens. This should be better. Really.
Fixes bug 14162; bug not in any released version of Tor.
In systemd 209, they deprecated -lsystemd-daemon in favor of
-lsystemd. So we'd better actually look at the pkg-config output,
or we'll get warnings on newer distributions.
For some as-yet-unknown-to-me reason, setting CFLAGS so early makes
it so -O2 -g doesn't get added to it later. So, adding it myself
later. Perhaps a better fix here can be found.
Fixes 14072; bugfix on 0.2.6.2-alpha. Based on a patch from h.venev
It work by notifying systemd on a regular basis. If
there is no notification, the daemon is restarted.
This requires a version newer than the 209 version
of systemd, as it is not supported before.
The original call to getsockopt to know the original address on transparently
proxyed sockets using REDIRECT in iptables failed with IPv6 addresses because
it assumed all sockets used IPv4.
This patch fixes this by using the appropriate options and adding the headers
containing the needed definitions for these.
This patch is released under the same license as the original file as
long as the author iscredited.
Signed-off-by: Francisco Blas Izquierdo Riera (klondike) <klondike@gentoo.org>
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.
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.
c99 lets us do neat stuff like:
{
int j, k;
foo(&j, &k);
int z = j + k;
}
and also
struct point { int x; int y; };
struct point pt = { .x=5, .y=5 };
This commit makes the configure scripts check to make sure your
compiler implements them. It also disables our longstanding warning
about midblock declarations.
Closes ticket 13233.
torrc.minimal is now the one that should change as infrequently as
possible. To schedule an change to go into it eventually, make your
change to torrc.minimal.in-sample.
torrc.sample is now the volatile one: we can change it to our hearts'
content.
Closes ticket #11144
We added some AS_VAR_IF-based checks to detect whether we have
managed to compile (but not link) with stack-protector. On autoconf
before 2.63, we don't have AS_VAR_IF, so we just have to let the
user get a compile error rather than a helpful "find libssp" error.
Fixes bug 12693; bugfix on 0.2.5.2-alpha (commit 21ac292820)
When building with bufferevents enabled, configure.ac throws an
error if "$ac_cv_header_event2_bufferevent_ssl_h" is not set to
"yes". However, nowhere was AC_CHECK_HEADERS(event2/bufferevent_ssl.h)
done. This commit adds the check.
Long ago we supported systems where there was no support for
threads, or where the threading library was broken. We shouldn't
have do that any more: on every OS that matters, threads exist, and
the OS supports running threads across multiple CPUs.
This resolves tickets 9495 and 12439. It's a prerequisite to making
our workqueue code work better, since sensible workqueue
implementations don't split across multiple processes.
