In order to be able to deploy the authenticated SENDMEs, these two consensus
parameters are needed to control the minimum version that we can emit and
accept.
See section 4 in prop289 for more details.
Note that at this commit, the functions that return the values aren't used so
compilation fails if warnings are set to errors.
Closes#26842
Signed-off-by: David Goulet <dgoulet@torproject.org>
Previously, we would only close the stream when our deliver window was
negative at the circuit-level but _not_ at the stream-level when receiving a
DATA cell.
This commit adds an helper function connection_edge_end_close() which
sends an END and then mark the stream for close for a given reason.
That function is now used both in case the deliver window goes below zero for
both circuit and stream level.
Part of #26840
Signed-off-by: David Goulet <dgoulet@torproject.org>
When we are about to send a DATA cell, we have to decrement the package window
for both the circuit and stream level.
This commit adds helper functions to handle the package window decrement.
Part of #26288
Signed-off-by: David Goulet <dgoulet@torproject.org>
When we get a relay DATA cell delivered, we have to decrement the deliver
window on both the circuit and stream level.
This commit adds helper functions to handle the deliver window decrement.
Part of #26840
Signed-off-by: David Goulet <dgoulet@torproject.org>
This is a bit of a complicated commit. It moves code but also refactors part
of it. No behavior change, the idea is to split things up so we can better
handle and understand how SENDME cells are processed where ultimately it will
be easier to handle authenticated SENDMEs (prop289) using the intermediate
functions added in this commit.
The entry point for the cell arriving at the edge (Client or Exit), is
connection_edge_process_relay_cell() for which we look if it is a circuit or
stream level SENDME. This commit refactors that part where two new functions
are introduced to process each of the SENDME types.
The sendme_process_circuit_level() has basically two code paths. If we are a
Client (the circuit is origin) or we are an Exit. Depending on which, the
package window is updated accordingly. Then finally, we resume the reading on
every edge streams on the circuit.
The sendme_process_stream_level() applies on the edge connection which will
update the package window if needed and then will try to empty the inbuf if
need be because we can now deliver more cells.
Again, no behavior change but in order to split that code properly into their
own functions and outside the relay.c file, code modification was needed.
Part of #26840.
Signed-off-by: David Goulet <dgoulet@torproject.org>
Take apart the SENDME cell specific code and put it in sendme.{c|h}. This is
part of prop289 that implements authenticated SENDMEs.
Creating those new files allow for the already huge relay.c to not grow in LOC
and makes it easier to handle and test the SENDME cells in an isolated way.
This commit only moves code. No behavior change.
Signed-off-by: David Goulet <dgoulet@torproject.org>
The nodelist_idx for each node_t serves as a unique identifier for
the node, so we can use a bitarray to hold all the excluded
nodes, and then remove them from the smartlist.
Previously use used smartlist_subtract(sl, excluded), which is
O(len(sl)*len(excluded)).
We can use this function in other places too, but this is the one
that showed up on the profiles of 30291.
Closes ticket 30307.
This command does not fit perfectly with the others, since its
second argument is optional and may contain equal signs. Still,
it's probably better to squeeze it into the new metaformat, since
doing so allows us to remove several pieces of the old
command-parsing machinery.
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.
(This should be all of the command that work nicely with positional
arguments only.)
Some of these commands should probably treat extra arguments as
incorrect, but for now I'm trying to be careful not to break
any existing users.
The first line break in particular was mishandled: it was discarded
if no arguments came before it, which made it impossible to
distinguish arguments from the first line of the body.
To solve this, we need to allocate a copy of the command rather than
using NUL to separate it, since we might have "COMMAND\n" as our input.
Fixes ticket 29984.
There _is_ an underlying logic to these commands, but it isn't
wholly uniform, given years of tweaks and changes. Fortunately I
think there is a superset that will work.
This commit adds a parser for some of the most basic cases -- the
ones currently handled by getargs_helper() and some of the
object-taking ones. Soon will come initial tests; then I'll start using
the parser.
After that, I'll expand the parser to handle the other cases that come
up in the controller protocol.
We have checks in various places in mainlook.c to make sure that
events are initialized before we invoke any periodic_foo() functions
on them. But now that each subsystem will own its own periodic
events, it will be cleaner if we don't assume that they are all
setup or not.
The end goal here is to move the periodic callback to their
respective modules, so that mainloop.c doesn't have to include so
many other things.
This patch doesn't actually move any of the callbacks out of
mainloop.c yet.
In this patch we lower the log level of the failures for the three calls
to unlink() in networkstatus_set_current_consensus(). These errors might
trigger on Windows because the memory mapped consensus file keeps the
file in open state even after we have close()'d it. Windows will then
error on the unlink() call with a "Permission denied" error.
The consequences of ignoring these errors is that we leave an unused
file around on the file-system, which is an easier way to fix this
problem right now than refactoring networkstatus_set_current_consensus().
See: https://bugs.torproject.org/29930
In "make test-network-all", test IPv6-only v3 single onion services,
using the chutney network single-onion-v23-ipv6-md. This test will
not pass until 23588 has been merged.
Closes ticket 27251.
Disable padding via limit check and machine condition. Limits cause us to stop
sending padding. Machine conditions cause the machines to be shut down, and
not restarted.
In 0.3.4 and later, these functions are declared in rephist.h:
STATIC uint64_t find_largest_max(bw_array_t *b);
STATIC void commit_max(bw_array_t *b);
STATIC void advance_obs(bw_array_t *b);
But in 0.2.9, they are declared in rephist.c and test_relay.c.
So compilers fail with a "must use 'struct' tag" error.
We add the missing struct typedef in test_relay.c, to match the
declarations in rephist.c.
(Merge commit 813019cc57 moves these functions into rephist.h instead.)
Fixes bug 30184; not in any released version of Tor.
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>
In 0.3.4 and later, we declare write_array as:
extern struct bw_array_t *write_array;
...
typedef struct bw_array_t bw_array_t;
But in 0.2.9, we declare write_array as:
typedef struct bw_array_t bw_array_t;
extern bw_array_t *write_array;
And then again in rephist.c:
typedef struct bw_array_t bw_array_t;
So some compilers fail with a duplicate declaration error.
We backport 684b396ce5, which removes the duplicate declaration.
And this commit deals with the undeclared type error.
Backports a single line from merge commit 813019cc57.
Fixes bug 30184; not in any released version of Tor.
We need to encode here instead of doing escaped(), since fwict
escaped() does not currently handle NUL bytes.
Also, use warn_if_nul_found in more cases to avoid duplication.
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>
The smartlist code takes great care to set all unused pointers inside
the smartlist memory to NULL. Check if this is also the case after
modifying the smartlist multiple times.
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.
Coverity doesn't like to see a path where we test a pointer for
NULL if we have already ready dereferenced the pointer on that
path. While in this case, the check is not needed, it's best not to
remove checks from the unit tests IMO. Instead, I'm adding an
earlier check, so that coverity, when analyzing this function, will
think that we have always checked the pointer before dereferencing
it.
Closes ticket 30180; CID 1444641.
Use a table-based lookup to find the right command handler. This
will serve as the basement for several future improvements, as we
improve the API for parsing commands.
This should please coverity, and fix CID 1415721. It didn't
understand that networkstatus_get_param() always returns a value
between its minimum and maximum values.
This should please coverity, and fix CID 1415722. It didn't
understand that networkstatus_get_param() always returns a value
between its minimum and maximum values.
This should please coverity, and fix CID 1415723. It didn't understand
that networkstatus_get_param() always returns a value between its
minimum and maximum values.
The logic here should be "use versions or free it". The "free it"
part was previously in a kind of obfuscated place, so coverity
wasn't sure it was invoked as appropriate. CID 1437436.
The function compat_getdelim_ is used for tor_getline if tor is compiled
on a system that lacks getline and getdelim. These systems should be
very rare, considering that getdelim is POSIX.
If this system is further a 32 bit architecture, it is possible to
trigger a double free with huge files.
If bufsiz has been already increased to 2 GB, the next chunk would
be 4 GB in size, which wraps around to 0 due to 32 bit limitations.
A realloc(*buf, 0) could be imagined as "free(*buf); return malloc(0);"
which therefore could return NULL. The code in question considers
that an error, but will keep the value of *buf pointing to already
freed memory.
The caller of tor_getline() would free the pointer again, therefore
leading to a double free.
This code can only be triggered in dirserv_read_measured_bandwidths
with a huge measured bandwith list file on a system that actually
allows to reach 2 GB of space through realloc.
It is not possible to trigger this on Linux with glibc or other major
*BSD systems even on unit tests, because these systems cannot reach
so much memory due to memory fragmentation.
This patch is effectively based on the penetration test report of
cure53 for curl available at https://cure53.de/pentest-report_curl.pdf
and explained under section "CRL-01-007 Double-free in aprintf() via
unsafe size_t multiplication (Medium)".
If the concatenation of connection buffer and the buffer of linked
connection exceeds INT_MAX bytes, then buf_move_to_buf returns -1 as an
error value.
This value is currently casted to size_t (variable n_read) and will
erroneously lead to an increasement of variable "max_to_read".
This in turn can be used to call connection_buf_read_from_socket to
store more data inside the buffer than expected and clogging the
connection buffer.
If the linked connection buffer was able to overflow INT_MAX, the call
of buf_move_to_buf would have previously internally triggered an integer
overflow, corrupting the state of the connection buffer.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Many buffer functions have a hard limit of INT_MAX for datalen, but
this limitation is not enforced in all functions:
- buf_move_all may exceed that limit with too many chunks
- buf_move_to_buf exceeds that limit with invalid buf_flushlen argument
- buf_new_with_data may exceed that limit (unit tests only)
This patch adds some annotations in some buf_pos_t functions to
guarantee that no out of boundary access could occur even if another
function lacks safe guards against datalen overflows.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
If the concatenation of connection buffer and the buffer of linked
connection exceeds INT_MAX bytes, then buf_move_to_buf returns -1 as an
error value.
This value is currently casted to size_t (variable n_read) and will
erroneously lead to an increasement of variable "max_to_read".
This in turn can be used to call connection_buf_read_from_socket to
store more data inside the buffer than expected and clogging the
connection buffer.
If the linked connection buffer was able to overflow INT_MAX, the call
of buf_move_to_buf would have previously internally triggered an integer
overflow, corrupting the state of the connection buffer.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Many buffer functions have a hard limit of INT_MAX for datalen, but
this limitation is not enforced in all functions:
- buf_move_all may exceed that limit with too many chunks
- buf_move_to_buf exceeds that limit with invalid buf_flushlen argument
- buf_new_with_data may exceed that limit (unit tests only)
This patch adds some annotations in some buf_pos_t functions to
guarantee that no out of boundary access could occur even if another
function lacks safe guards against datalen overflows.
[This is a backport of the submitted patch to 0.2.9, where the
buf_move_to_buf and buf_new_with_data functions did not exist.]
Fixes bug 29922; bugfix on 0.2.9.3-alpha when we tried to capture
all these warnings. No need to backport any farther than 0.3.5,
though -- these warnings don't cause test failures before then.
This one was tricky to find because apparently it only happened on
_some_ windows builds.
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.
This test was disabled in 0.4.0 and later, but the fix in #29298 was only
merged to 0.4.1. So this test will never be re-enabled in 0.4.0.
Part of 29500.
Our monotime mocking forces us to call monotime_init() *before* we set the
mocked time value. monotime_init() thus stores the first ratchet value at
whatever the platform is at, and then we set fake mocked time to some later
value.
If monotime_init() gets a value from the host that is greater than what we
choose to mock time at for our unittests, all subsequent monotime_abosolute()
calls return zero, which breaks all unittests that depend on time moving
forward by updating mocked monotime values.
So, we need to adjust our mocked time to take the weird monotime_init() time
into account, when we set fake time.
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.
When classifying a client's selection of TLS ciphers, if the client
ciphers are not yet available, do not cache the result. Previously,
we had cached the unavailability of the cipher list and never looked
again, which in turn led us to assume that the client only supported
the ancient V1 link protocol. This, in turn, was causing Stem
integration tests to stall in some cases. Fixes bug 30021; bugfix
on 0.2.4.8-alpha.
When we fixed 28614, our answer was "if we failed to load the
consensus on windows and it had a CRLF, retry it." But we logged
the failure at "warn", and we only logged the retry at "info".
Now we log the retry at "notice", with more useful information.
Fixes bug 30004.
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.
Previously we used time(NULL) to set the Expires: header in our HTTP
responses. This made the actual contents of that header untestable,
since the unit tests have no good way to override time(), or to see
what time() was at the exact moment of the call to time() in
dircache.c.
This gave us a race in dir_handle_get/status_vote_next_bandwidth,
where the time() call in dircache.c got one value, and the call in
the tests got another value.
I'm applying our regular solution here: using approx_time() so that
the value stays the same between the code and the test. Since
approx_time() is updated on every event callback, we shouldn't be
losing any accuracy here.
Fixes bug 30001. Bug introduced in fb4a40c32c4a7e5; not in any
released Tor.
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>
When a directory authority is using a bandwidth file to obtain the
bandwidth values that will be included in the next vote, serve this
bandwidth file at /tor/status-vote/next/bandwidth.z.
Let's use the same function exit point for BUG() codepath that we're using
for every other exit condition. That way, we're not forgetting to clean up
the memarea.
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}_()
This is necessary to get the number of includes in main.c back under
control. (In the future, we could just use the subsystem manager for
this kind of stuff.)
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.
Previously, or_connection_t did not record whether or not the
connection uses a pluggable transport. Instead, it stored the
underlying proxy protocol of the pluggable transport in
proxy_type. This made bootstrap reporting treat pluggable transport
connections as plain proxy connections.
Store a separate bit indicating whether a pluggable transport is in
use, and decode this during bootstrap reporting.
Fixes bug 28925; bugfix on 0.4.0.1-alpha.
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
The name of circpad_machine_state_t was very confusing since it was conflicting
with circpad_state_t and circpad_circuit_state_t.
Right now here is the current meaning of these structs:
circpad_state_t -> A state of the state machine.
circpad_machine_runtime_t -> The current mutable runtime info of the state machine.
circpad_circuit_state_t -> Circuit conditions based on which we should apply a machine to the circuit
so that the relays that would be "excluded" from the bandwidth
file because of something failed can be included to diagnose what
failed, without still including these relays in the bandwidth
authorities vote.
Closes#29806.
This is something we should think about harder, but we probably want dormant
mode to be more powerful than padding in case a client has been inactive for a
day or so. After all, there are probably no circuits open at this point and
dormant mode will not allow the client to open more circuits.
Furthermore, padding should not block dormant mode from being activated, since
dormant mode relies on SocksPort activity, and circuit padding does not mess
with that.
They are simply not used apart from assigning a pointer and asserting on the
pointer depending on the cell direction.
Closes#29196.
Signed-off-by: David Goulet <dgoulet@torproject.org>
Allow connections to single onion services to remain idle without being
disconnected.
Relays acting as rendezvous points for single onion services were
mistakenly closing idle established rendezvous circuits after 60 seconds,
thinking that they are unused directory-fetching circuits that had served
their purpose.
Fixes bug 29665; bugfix on 0.2.1.26.
Allow connections to single onion services to remain idle without being
disconnected.
Relays acting as rendezvous points for single onion services were
mistakenly closing idle established rendezvous circuits after 60 seconds,
thinking that they are unused directory-fetching circuits that had served
their purpose.
Fixes bug 29665; bugfix on 0.2.1.26.
They were causing the following warnings in circuitpadding/circuitpadding_sample_distribution:
src/lib/math/prob_distr.c:1311:17: runtime error: division by zero
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/lib/math/prob_distr.c:1311:17 in
src/lib/math/prob_distr.c:1219:49: runtime error: division by zero
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/lib/math/prob_distr.c:1219:49 in
because the distributions were called with erroneous parameters (e.g. geometric
distribution with p=0).
We now defined these test probability distributions with more realistic
parameters.
As far as the circuitpadding_sample_distribution() test is concerned, it
doesn't matter if the distributions return values outside of [0,10] since we
already restrict the values into that interval using min=0 and max=10 (and RTT
estimate is disabled).
The previous commits introduced link_specifier_dup(), which is
implemented using trunnel's opaque interfaces. So we can now
remove hs_desc_link_specifier_dup().
Cleanup after bug 22781.
Cleanup some bugs discovered during 23576:
* stop copying the first 20 characters of a 40-character hex string
to a binary fingerprint
* stop putting IPv6 addresses in a variable called "ipv4"
* explain why we do a duplicate tt_int_op() to deliberately fail and
print a value
Fixes bug 29243; bugfix on 0.3.2.1-alpha.
The previous commits for 23576 confused hs_desc_link_specifier_t
and link_specifier_t. Removing hs_desc_link_specifier_t fixes this
confusion.
Fixes bug 22781; bugfix on 0.3.2.1-alpha.
Check if the new pointer is the same as the old one: if it is, it's
probably a bug:
* the caller may have confused current and previous, or
* they may have forgotten to sr_srv_dup().
Putting NULL multiple times is allowed.
Part of 29706.
Refactor the shared random state's memory management so that it actually
takes ownership of the shared random value pointers.
Fixes bug 29706; bugfix on 0.2.9.1-alpha.
Stop leaking parts of the shared random state in the shared-random unit
tests. The previous fix in 29599 was incomplete.
Fixes bug 29706; bugfix on 0.2.9.1-alpha.
Turns out that when reloading a tor configured with hidden service(s), we
weren't copying all the needed information between the old service object to
the new one.
For instance, the desc_is_dirty timestamp wasn't which could lead to the
service uploading its descriptor much later than it would need to.
The replaycache wasn't also moved over and some intro point information as
well.
Fixes#23790
Signed-off-by: David Goulet <dgoulet@torproject.org>
This commit also explicitly set the value of the PRT enum so we can match/pin
the C enum values to the Rust one in protover/ffi.rs.
Fixes#29631
Signed-off-by: David Goulet <dgoulet@torproject.org>
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.
* Move out code that depends on NSS to crypto_digest_nss.c
* Move out code that depends on OpenSSL to crypto_digest_openssl.c
* Keep the general code that is not specific to any of the above in
crypto_digest.c
Prior to #23100, we were not counting HS circuit build times in our
calculation of the timeout. This could lead to a condition where our timeout
was set too low, based on non HS circuit build times, and then we would
abandon all HS circuits, storing no valid timeouts in the histogram.
This commit avoids the assert.
When "auto" was used for the port number for a listening socket, the
message logged after opening the socket would incorrectly say port 0
instead of the actual port used.
Fixes bug 29144; bugfix on 0.3.5.1-alpha
Signed-off-by: Kris Katterjohn <katterjohn@gmail.com>
This patch fixes a crash bug (assertion failure) in the PT subsystem
that could get triggered if the user cancels bootstrap via the UI in
TorBrowser. This would cause Tor to call `managed_proxy_destroy()` which
called `process_free()` after it had called `process_terminate()`. This
leads to a crash when the various process callbacks returns with data
after the `process_t` have been freed using `process_free()`.
We solve this issue by ensuring that everywhere we call
`process_terminate()` we make sure to detach the `managed_proxy_t` from
the `process_t` (by calling `process_set_data(process, NULL)`) and avoid
calling `process_free()` at all in the transports code. Instead we just
call `process_terminate()` and let the process exit callback in
`managed_proxy_exit_callback()` handle the `process_free()` call by
returning true to the process subsystem.
See: https://bugs.torproject.org/29562
Fixes bug 29530, where the LOG_ERR messages were occurring when
we had no configured network, and so we were failing the unit tests
because of the recently-merged #28668.
Commit message edited by teor:
We backported 28668 and released it in 0.3.5.8.
This commit backports 29530 to 0.3.5.
Fixes bug 29530 in Tor 0.3.5.8.
When IPv4Only (IPv6Only) was used but the address could not be
interpreted as a IPv4 (IPv6) address, the error message referred
to the wrong IP version.
This also fixes up the error-checking logic so it's more precise
about what's being checked.
Fixes bug 13221; bugfix on 0.2.3.9-alpha
Signed-off-by: Kris Katterjohn <katterjohn@gmail.com>
This test was previously written to use the contents of the system
headers to decide whether INHERIT_NONE or INHERIT_ZERO was going to
work. But that won't work across different environments, such as
(for example) when the kernel doesn't match the headers. Instead,
we add a testing-only feature to the code to track which of these
options actually worked, and verify that it behaved as we expected.
Closes ticket 29541; bugfix not on any released version of Tor.
