There were only two functions outside of circuitstats that actually
wanted to know what was inside this. Making the structure itself
hidden should help isolation and prevent us from spaghettifying the
thing more.
The spec requires them to do so, and not doing so creates a situation
where they can't send-test because relays won't extend to them because
of the other part of bug 9546.
Fixes bug 9546; bugfix on 0.2.3.6-alpha.
The spec requires them to do so, and not doing so creates a situation
where they can't send-test because relays won't extend to them because
of the other part of bug 9546.
Fixes bug 9546; bugfix on 0.2.3.6-alpha.
(Backport to Tor 0.2.3)
Relays previously, when initiating a connection, would only send a
NETINFO after sending an AUTHENTICATE. But bridges, when receiving a
connection, would never send AUTH_CHALLENGE. So relays wouldn't
AUTHENTICATE, and wouldn't NETINFO, and then bridges would be
surprised to be receiving CREATE cells on a non-open circuit.
Fixes bug 9546.
Relays previously, when initiating a connection, would only send a
NETINFO after sending an AUTHENTICATE. But bridges, when receiving a
connection, would never send AUTH_CHALLENGE. So relays wouldn't
AUTHENTICATE, and wouldn't NETINFO, and then bridges would be
surprised to be receiving CREATE cells on a non-open circuit.
Fixes bug 9546.
Use the generic function for both the ControlPort cookie and the
ExtORPort cookie.
Also, place the global cookie variables in the heap so that we can
pass them around more easily as pointers.
Also also, fix the unit tests that broke by this change.
Conflicts:
src/or/config.h
src/or/ext_orport.c
memwipe some stack-allocated stuff
Add DOCDOC comments for state machines
Use memdup_nulterm as appropriate
Check for NULs in useraddr
Add a macro so that <= AUTH_MAX has a meaning.
- Don't leak if a transport proxy sends us a TRANSPORT command more
than once.
- Don't use smartlist_string_isin() in geoip_get_transport_history().
(pointed out by Nick)
- Use the 'join' argument of smartlist_join_strings() instead of
trying to write the separator on our own.
(pointed out by Nick)
- Document 'ext_or_transport' a bit better.
(pointed out by Nick)
- Be a bit more consistent with the types of the values of 'transport_counts'.
(pointed out by Nick)
Fortunately, later checks mean that uninitialized data can't get sent
to the network by this bug. Unfortunately, reading uninitialized heap
*can* (in some cases, with some allocators) cause a crash if you get
unlucky and go off the end of a page.
Found by asn. Bugfix on 0.2.4.1-alpha.
Both 'managed_proxy_list' and 'unconfigured_proxies_n' are global
src/or/transports.c variables that are not initialized properly when
unit tests are run.
When we moved channel_matches_target_addr_for_extend() into a separate
function, its sense was inverted from what one might expect, and we
didn't have a ! in one place where we should have.
Found by skruffy.
When we moved channel_matches_target_addr_for_extend() into a separate
function, its sense was inverted from what one might expect, and we
didn't have a ! in one place where we should have.
Found by skruffy.
I added this so I could write a unit test for ServerTransportOptions,
but it incidentally exercises the succeed-on-defaults case of
options_validate too.
Previously we would accept relative paths, but only if they contained a
slash somewhere (not at the end).
Otherwise we would silently not work. Closes: #9258. Bugfix on
0.2.3.16-alpha.
If you pass the --enable-coverage flag on the command line, we build
our testing binaries with appropriate options eo enable coverage
testing. We also build a "tor-cov" binary that has coverage enabled,
for integration tests.
On recent OSX versions, test coverage only works with clang, not gcc.
So we warn about that.
Also add a contrib/coverage script to actually run gcov with the
appropriate options to generate useful .gcov files. (Thanks to
automake, the .o files will not have the names that gcov expects to
find.)
Also, remove generated gcda and gcno files on clean.
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.
This is mainly a matter of automake trickery: we build each static
library in two versions now: one with the TOR_UNIT_TESTS macro
defined, and one without. When TOR_UNIT_TESTS is defined, we can
enable mocking and expose more functions. When it's not defined, we
can lock the binary down more.
The alternatives would be to have alternate build modes: a "testing
configuration" for building the libraries with test support, and a
"production configuration" for building them without. I don't favor
that approach, since I think it would mean more people runnning
binaries build for testing, or more people not running unit tests.
Fix a bug in the voting algorithm that could yield incorrect results
when a non-naming authority declared too many flags. Fixes bug 9200;
bugfix on 0.2.0.3-alpha.
Found by coverity scan.
This implements "algorithm 1" from my discussion of bug #9072: on OOM,
find the circuits with the longest queues, and kill them. It's also a
fix for #9063 -- without the side-effects of bug #9072.
The memory bounds aren't perfect here, and you need to be sure to
allow some slack for the rest of Tor's usage.
This isn't a perfect fix; the rest of the solutions I describe on
codeable.
In my #7912 fix, there wasn't any code to remove entries from the
(channel, circuit ID)->circuit map corresponding to queued but un-sent
DESTROYs.
Spotted by skruffy. Fixes bug 9082; bug not in any released Tor.
I added the code to pass a destroy cell to a queueing function rather
than writing it immediately, and the code to remember that we
shouldn't reuse the circuit id until the destroy is actually sent, and
the code to release the circuit id once the destroy has been sent...
and then I finished by hooking destroy_cell_queue into the rest of
Tor.
This is a reprise of the fix in bdff7e3299d78; 6905c1f6 reintroduced
that bug. Briefly: windows doesn't seem to like deleting a mapped
file. I tried adding the PROT_SHARED_DELETE flag to the createfile
all, but that didn't actually fix this issue. Fortunately, the unit
test I added in 4f4fc63fea should
prevent us from making this particular screw-up again.
This patch also tries to limit the crash potential of a failure to
write by a little bit, although it could do a better job of retaining
microdescriptor bodies.
Fix for bug 8822, bugfix on 0.2.4.12-alpha.
There's an assertion failure that can occur if a connection has
optimistic data waiting, and then the connect() call returns 0 on the
first attempt (rather than -1 and EINPROGRESS). That latter behavior
from connect() appears to be an (Open?)BSDism when dealing with remote
addresses in some cases. (At least, I've only seen it reported with
the BSDs under libevent, even when the address was 127.0.0.1. And
we've only seen this problem in Tor with OpenBSD.)
Fixes bug 9017; bugfix on 0.2.3.1-alpha, which first introduced
optimistic data. (Although you could also argue that the commented-out
connection_start_writing in 155c9b80 back in 2002 is the real source
of the issue.)
A new option TestingV3AuthVotingStartOffset is added which offsets the
starting time of the voting interval. This is possible only when
TestingTorNetwork is set.
This patch makes run_scheduled_events() check for new consensus
downloads every second when TestingTorNetwork, instead of every
minute. This should be fine, see #8532 for reasoning.
This patch also brings MIN_VOTE_SECONDS and MIN_DIST_SECONDS down from
20 to 2 seconds, unconditionally. This makes sanity checking of
misconfiguration slightly less sane.
Addresses #8532.
You can't use != to compare arbitary members of or_options_t.
(Also, generate a better error message to say which Testing* option
was set.)
Fix for bug 8992. Bugfix on b0d4ca49. Bug not in any released Tor.
- Rename n_read and n_written in origin_circuit_t to make it clear that
these are only used for CIRC_BW events.
- Extract new code in control_update_global_event_mask to new
clear_circ_bw_fields function.
- Avoid control_event_refill_global function with 13 arguments and
increase code reuse factor by moving more code from control.c to
connection.c.
- Avoid an unsafe uint32_t -> int cast.
- Add TestingEnableTbEmptyEvent option.
- Prepare functions for testing.
- Rename a few functions and improve documentation.
- Move cell_command_to_string from control.c to command.c.
- Use accessor for global_circuitlist instead of extern.
- Add a struct for cell statistics by command instead of six arrays.
- Split up control_event_circuit_cell_stats by using two helper functions.
- Add TestingEnableCellStatsEvent option.
- Prepare functions for testing.
- Rename a few variables and document a few things better.
- Move new ID= parameter in ORCONN event to end. Avoids possible trouble
from controllers that parse parameters by position, even though they
shouldn't.
Create new methods check_or_create_data_subdir() and
write_to_data_subdir() in config.c and use them throughout
rephist.c and geoip.c.
This should solve ticket #4282.
This is a fix for bug 8844, where eugenis correctly notes that there's
a sentinel value at the end of the list-of-freelists that's never
actually checked. It's a bug since the first version of the chunked
buffer code back in 0.2.0.16-alpha.
This would probably be a crash bug if it ever happens, but nobody's
ever reported something like this, so I'm unsure whether it can occur.
It would require write_to_buf, write_to_buf_zlib, read_to_buf, or
read_to_buf_tls to get an input size of more than 32K. Still, it's a
good idea to fix this kind of thing!
It appears that moria1 crashed because of one instance of this (the
one in router_counts_toward_thresholds). The other instance I fixed
won't actually have broken anything, but I think it's more clear this
way.
Fixes bug 8833; bugfix on 0.2.4.12-alpha.
We need to subtract both the current built circuits *and* the attempted
circuits from the attempt count during scaling, since *both* have already been
counted there.
It sure is a good thing we can run each test in its own process, or
else the amount of setup I needed to do to make this thing work
would have broken all the other tests.
Test mocking would have made this easier to write too.
