| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
|
|
Make sure to memset(0) the destination buffer so we don't leave any
uninitialized data.
Fixes #19462
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
Yes, HURD lacks PATH_MAX. But we already limited the maximum buffer
to 4096, so why not just use that?
|
|
|
|
|
|
base16_decodes() now returns the number of decoded bytes. It's interface
changes from returning a "int" to a "ssize_t". Every callsite now checks the
returned value.
Fixes #14013
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
|
|
|
|
|
|
realloc()ing a thing in order to try to save memory on it just
doesn't make sense with today's allocators. Instead, let's use the
fact that whenever we decompress something, either it isn't too big,
or we chop it up, or we reallocate it.
|
|
zlib 1.2 came out in 2003; earlier versions should be dead by now.
Our workaround code was only preventing us from using the gzip
encoding (if we decide to do so), and having some dead code linger
around in torgzip.c
|
|
|
|
|
|
|
|
Fixes #18280
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
|
|
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.
|
|
|
|
All of our code just uses parse_config_line_from_str_verbose.
|
|
Also, add tests for it in case someday it does become reachable.
|
|
Also note a bug in the rate-limiting message.
|
|
|
|
it's important, and we should make sure we got it right.
|
|
Fix for bug 19428.
|
|
|
|
I audited this to make sure I was only marking ones that really
should be unreachable.
|
|
|
|
|
|
Another part of 19406
|
|
|
|
This is a logging onlu change, we were suppressing the severity down to
INFO when it occured (treating it as "Mostly harmless"). Now it is no
more.
|
|
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.
|
|
Instead of `ERR_remove_thread_state()` having a modified prototype, it
now has the old prototype and a deprecation annotation. Since it's
pointless to add extra complexity just to remain compatible with an old
OpenSSL development snapshot, update the code to work with 1.1.0pre5
and later.
|
|
|
|
|
|
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 gives more accurate results under Clang, which can only help us
detect more warnings in more places.
Fixes bug 19216; bugfix on 0.2.0.1-alpha
|
|
This caught quite a few minor issues in our unit tests and elsewhere
in our code.
|
|
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.
|
|
|
|
These are all related to failures from functions that either can't
fail as we call them, or where we cannot provoke failure.
|
|
So, back long ago, XXX012 meant, "before Tor 0.1.2 is released, we
had better revisit this comment and fix it!"
But we have a huge pile of such comments accumulated for a large
number of released versions! Not cool.
So, here's what I tried to do:
* 0.2.9 and 0.2.8 are retained, since those are not yet released.
* XXX+ or XXX++ or XXX++++ or whatever means, "This one looks
quite important!"
* The others, after one-by-one examination, are downgraded to
plain old XXX. Which doesn't mean they aren't a problem -- just
that they cannot possibly be a release-blocking problem.
|
|
Suppress it in the one spot in the code where we actually do want to
allow an aggregate return in order to call the mallinfo() API.
|
|
Previously we'd done this ad hoc.
|
|
There are a few places where we want to disable a warning: for
example, when it's impossible to call a legacy API without
triggering it, or when it's impossible to include an external header
without triggering it.
This pile of macros uses GCC's c99 _Pragma support, plus the usual
macro trickery, to enable and disable warnings.
|
|
|
|
|
|
|
