When parsing addreses via Tor's internal DNS lookup API:
* reject IPv4 addresses in square brackets (with or without a port),
* accept IPv6 addresses in square brackets (with or without a port), and
* accept IPv6 addresses without square brackets, as long as they have no port.
This change completes the work started in 23082, making address parsing
consistent between tor's internal DNS lookup and address parsing APIs.
Fixes bug 30721; bugfix on 0.2.1.5-alpha.
"unsettable" is a property of types. LINELIST_V and OBSOLETE are
unsettable, meaning that they cannot be set by name.
"contained" is a property of types. I'm hoping to find a better
name here. LINELIST_S is "contained" because it always appears
within a LINELIST_V, and as such doesn't need to be dumped ore
copied independently.
"cumulative" is a property of types. Cumulative types can appear
more than once in a torrc without causing a warning, because they
add to each other rather than replacing each other.
"obsolete" is a property of variables.
"marking fragile" is now a command that struct members can accept.
With these changes, confparse and config no longer ever need to
mention CONFIG_TYPE_XYZ values by name.
Right now, this has been done at a high level by confparse.c, but it
makes more sense to lower it.
This API is radically un-typesafe as it stands; we'll be wrapping it
in a safer API as we do #30914 and lower the struct manipulation
code as well.
Closes ticket 30864.
Note that the event base object is _not_ created from the initialize
function, since it is configuration-dependent. This will wait until
configuration is integrated into subsystems.
Closes ticket 30806.
Fixes assertion failure in tests on NetBSD:
slow/prob_distr/stochastic_log_logistic: [forking] May 25 03:56:58.091 [err] tor_assertion_failed_(): Bug: src/lib/crypt_ops/crypto_rand_fast.c:184: crypto_fast_rng_new_from_seed: Assertion inherit != INHERIT_RES_KEEP failed; aborting. (on Tor 0.4.1.1-alpha-dev 29955f13e5)
May 25 03:56:58.091 [err] Bug: Assertion inherit != INHERIT_RES_KEEP failed in crypto_fast_rng_new_from_seed at src/lib/crypt_ops/crypto_rand_fast.c:184: . (Stack trace not available) (on Tor 0.4.1.1-alpha-dev 29955f13e5)
[Lost connection!]
The ordinary definitions of timeradd() and timersub() contain a
branch. However, in coverage builds, this means that we get spurious
complaints about partially covered basic blocks, in a way that makes
our coverage determinism harder to check.
Ordinarily we skip calling log_fn(LOG_DEBUG,...) if debug logging is
completely disabled. However, in coverage builds, this means that
we get spurious complaints about partially covered basic blocks, in
a way that makes our coverage determinism harder to check.
I don't believe any of these represent a real timing vulnerability
(remote timing against memcmp() on a modern CPU is not easy), but
these are the ones where I believe we should be more careful.
For memeq and friends, "tor_" indicates constant-time and "fast_"
indicates optimized. I'm fine with leaving the constant-time
"safe_mem_is_zero" with its current name, but the "tor_" prefix on
the current optimized version is misleading.
Also, make the tor_digest*_is_zero() uniformly constant-time, and
add a fast_digest*_is_zero() version to use as needed.
A later commit in this branch will fix all the users of
tor_mem_is_zero().
Closes ticket 30309.
The two options are mutually exclusive, since otherwise an entry
like "Foo" would be ambiguous. We want to have the ability to treat
entries like this as keys, though, since some controller commands
interpret them as flags.
When releasing OpenSSL patch-level maintenance updates,
we do not want to rebuild binaries using it.
And since they guarantee ABI stability, we do not have to.
Without this patch, warning messages were produced
that confused users:
https://bugzilla.opensuse.org/show_bug.cgi?id=1129411
Fixes bug 30190; bugfix on 0.2.4.2-alpha commit 7607ad2bec
Signed-off-by: Bernhard M. Wiedemann <bwiedemann@suse.de>
The smartlist functions take great care to reset unused pointers inside
the smartlist memory to NULL.
The function smartlist_remove_keeporder does not clear memory in such
way when elements have been removed. Therefore call memset after the
for-loop that removes elements. If no element is removed, it is
effectively a no-op.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Previously, our use of abort() would break anywhere that we didn't
include stdlib.h. This was especially troublesome in case where
tor_assert_nonfatal() was used with ALL_BUGS_ARE_FATAL, since that
one seldom gets tested.
As an alternative, we could have just made this header include
stdlib.h. But that seems bloaty.
Fixes bug 30189; bugfix on 0.3.4.1-alpha.
In current NSS versions, these ciphersuites don't work with
SSL_ExportKeyingMaterial(), which was causing relays to fail when
they tried to negotiate the v3 link protocol authentication.
Fixes bug 29241; bugfix on 0.4.0.1-alpha.
And fix the documentation on the function: it does produce trailing
"="s as padding.
Also remove all checks for the return value, which were redundant anyway,
because the function never failed.
Part of 29660.
... and ed25519_public_to_base64(). Also remove all checks for the return
values, which were redundant anyway, because the functions never failed.
Part of 29960.
getpid() can be really expensive sometimes, and it can fail to
detect some kind of fork+prng mistakes, so we need to avoid it if
it's safe to do so.
This patch might slow down fast_prng a lot on any old operating
system that lacks a way to prevent ram from being inherited, AND
requires a syscall for any getpid() calls. But it should make sure
that we either crash or continue safely on incorrect fork+prng usage
elsewhere in the future.
This is just in case there is some rogue platform that uses a
nonstandard value for SEEK_*, and does not define that macro in
unistd.h. I think that's unlikely, but it's conceivable.
In 9c132a5f9e we replaced "buf" with a pointer and replaced
one instance of snprintf with asprintf -- but there was still one
snprintf left over, being crashy.
Fixes bug 29967; bug not in any released Tor. This is CID 1444262.
This can't actually result in a null pointer dereference, since
pub_excl and sub_excl are only set when the corresponding smartlists
are nonempty. But coverity isn't smart enough to figure that out,
and we shouldn't really be depending on it.
Bug 29938; CID 1444257. Bug not in any released Tor.
Having the numbers in those messages makes some of the unit test
unstable, by causing them to depend on the initialization order of
the naming objects.
Based on patches and review comments by Riastradh and Catalyst.
Co-authored-by: Taylor R Campbell <campbell+tor@mumble.net>
Co-authored-by: Taylor Yu <catalyst@torproject.org>
Previously, I had used integers encoded as pointers. This
introduced a flaw: NULL represented both the integer zero, and the
absence of a setting. This in turn made the checks in
cfg_msg_set_{type,chan}() not actually check for an altered value if
the previous value had been set to zero.
Also, I had previously kept a pointer to a dispatch_fypefns_t rather
than making a copy of it. This meant that if the dispatch_typefns_t
were changed between defining the typefns and creating the
dispatcher, we'd get the modified version.
Found while investigating coverage in pubsub_add_{pub,sub}_()
We want the DISPATCH_ADD_PUB() macro to count as making a
DECLARE_PUBLISH() invocation "used", so let's try a new approach
that preserves that idea. The old one apparently did not work for
some versions of osx clang.
This code tries to prevent a large number of possible errors by
enforcing different restrictions on the messages that different
modules publish and subscribe to.
Some of these rules are probably too strict, and some too lax: we
should feel free to change them as needed as we move forward and
learn more.
This "publish/subscribe" layer sits on top of lib/dispatch, and
tries to provide more type-safety and cross-checking for the
lower-level layer.
Even with this commit, we're still not done: more checking will come
in the next commit, and a set of usability/typesafety macros will
come after.
This module implements a way to send messages from one module to
another, with associated data types. It does not yet do anything to
ensure that messages are correct, that types match, or that other
forms of consistency are preserved.
We already do this in our log_debug() macro, but there are times
when we'd like to avoid allocating or precomputing something that we
are only going to log if debugging is on.
When NULL is given to lpApplicationName we enable Windows' "magical"
path interpretation logic, which makes Tor 0.4.x behave in the same way
as previous Tor versions did when it comes to executing binaries in
different system paths.
For more information about this have a look at the CreateProcessA()
documentation on MSDN -- especially the string interpretation example is
useful to understand this issue.
This bug was introduced in commit bfb94dd2ca.
See: https://bugs.torproject.org/29874
There's an incorrect comment in compat_time.c that suggests we call
FreeLibrary() before we're done using the library's functions.
See 29642 for background.
Closes ticket 29643.
