Otherwise, it always seems as though our Exclude* options have
changed, since we're comparing modified to unmodified values.
Patch from qwerty1. Fixes bug 9801. Bugfix on 0.2.4.10-alpha, where
GeoIPExcludeUnknown was introduced.
Currently tor fails to build its test when enabled with bufferevents
because an #ifndef USE_BUFFEREVENTS hides bucket_millis_empty() and
friends. This is fine if we don't run tests, but if we do, we need
these functions in src/or/libtor-testing.a when linking src/test/test.
This patch moves the functions outside the #ifndef and exposes them.
See downstream bug:
https://bugs.gentoo.org/show_bug.cgi?id=510124
When we run into bug 8387 (if we run into it again), report when we
last called circuit_expire_old_circuits_clientside(). This will let
us know -- if my fix for 8387 doesn't work -- whether my diagnosis
was at least correct.
Suggested by Andrea.
We should only assign a relay the HSDir flag if it is currently
considered valid. We can accomplish this by only considering active
relays, and as a consequence of this we also exclude relays that are
currently hibernating. Fixes#12573
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.
The variable was useless since it was only toggled off in disabled code.
If the 'exit_family' smartlist is empty, we don't consider exit family
anyway.
Check for consistency between the queued destroy cells and the marked
circuit IDs. Check for consistency in the count of queued destroy
cells in several ways. Check to see whether any of the marked circuit
IDs have somehow been marked longer than the channel has existed.
And add a comment about why conditions that would cause us to drop a
cell should get checked before actions that would cause us to send a
destroy cell.
Spotted by 'cypherpunks'.
And note that these issues have been present since 0.0.8pre1 (commit
0da256ef), where we added a "shutting down" state, and started
responding to all create cells with DESTROY when shutting down.
Conflicts:
src/or/channel.c
src/or/circuitlist.c
src/or/connection.c
Conflicts involved removal of next_circ_id and addition of
unusable-circid tracking.
The point of the "idle timeout" for connections is to kill the
connection a while after it has no more circuits. But using "last
added a non-padding cell" as a proxy for that is wrong, since if the
last circuit is closed from the other side of the connection, we
will not have sent anything on that connection since well before the
last circuit closed.
This is part of fixing 6799.
When applied to 0.2.5, it is also a fix for 12023.
Instead of killing an or_connection_t that has had no circuits for
the last 3 minutes, give every or_connection_t a randomized timeout,
so that an observer can't so easily infer from the connection close
time the time at which its last circuit closed.
Also, increase the base timeout for canonical connections from 3
minutes to 15 minutes.
Fix for ticket 6799.
When we find a stranded one-hop circuit, log whether it is dirty,
log information about any streams on it, and log information about
connections they might be linked to.
This code mis-handled the case where a circuit got the same circuit
ID in both directions. I found three instances of it in the
codebase, by grepping for [pn]_circ_id.
Because of the issue in command_process_relay_cell(), this would
have made roughly one circuit in a million completely nonfunctional.
Fixes bug 12195.
On some profiles of Andrea's from #11332, I found that a great deal
of time can still be attributed to functions called from
update_router_have_minimum_dir_info(). This is making our
digestmap, tor_memeq, and siphash functions take a much bigger
portion of runtime than they really should.
If we're calling update_router_have_minimum_dir_info() too often,
that's because we're calling router_dir_info_changed() too often.
And it looks like most of the callers of router_dir_info_changed()
are coming as tail-calls from router_set_status() as invoked by
channel_do_open_actions().
But we don't need to call router_dir_info_changed() so much! (I'm
not quite sure we need to call it from here at all, but...) Surely
we don't need to call it from router_set_status when the router's
status has not actually changed.
This patch makes us call router_dir_info_changed() from
router_set_status only when we are changing the router's status.
Fix for bug 12170. This is leftover from our fix back in 273ee3e81
in 0.1.2.1-alpha, where we started caching the value of
update_router_have_minimum_dir_info().
tor_memeq has started to show up on profiles, and this is one of the
most frequent callers of that function, appearing as it does on every
cell handled for entry or exit.
59f9097d5c introduced tor_memneq here;
it went into Tor 0.2.1.31. Fixes part of 12169.
Without this fix, when running with bridges, we would try fetching
directory info far too early, and have up to a 60 second delay if we
started with bridge descriptors available.
Fixes bug 11965. Fix on 0.2.3.6-alpha, arma thinks.
The old cache had problems:
* It needed to be manually preloaded. (It didn't remember any
address you didn't tell it to remember)
* It was AF_INET only.
* It looked at its cache even if the sandbox wasn't turned on.
* It couldn't remember errors.
* It had some memory management problems. (You can't use memcpy
to copy an addrinfo safely; it has pointers in.)
This patch fixes those issues, and moves to a hash table.
Fixes bug 11970; bugfix on 0.2.5.1-alpha.
The code was not disambiguating ClientTransportPlugin configured and
not used, and ClientTransportPlugin configured, but in a failed state.
The right thing to do is to undo moving the get_transport_by_addrport()
call back into get_proxy_addrport(), and remove and explicit check for
using a Bridge since by the time the check is made, if a Bridge is
being used, it is PT/proxy-less.
This change allows using Socks4Proxy, Socks5Proxy and HTTPSProxy with
ClientTransportPlugins via the TOR_PT_PROXY extension to the
pluggable transport specification.
This fixes bug #8402.
None of the things we might exec() can possibly run under the
sanbox, so rather than crash later, we have to refuse to accept the
configuration nice and early.
The longer-term solution is to have an exec() helper, but wow is
that risky.
fixes 12043; bugfix on 0.2.5.1-alpha
When we converted the horrible set of options that previously
controlled "use ORPort or DirPort? Anonymously or Non-anonymouly?" to
a single 'indirection' argument, we missed
directory_post_to_dirservers.
The problematic code was introduced in 5cbeb6080, which went into
0.2.4.3-alpha. This is a fix for bug 11469.
If somebody has configured a client to use a bridge without setting
an identity digest (not recommended), learn the identity digest from
whatever bridge descriptor we have downloaded or have in our cache.
When running with User set, we frequently try to look up our
information in the user database (e.g., /etc/passwd). The seccomp2
sandbox setup doesn't let us open /etc/passwd, and probably
shouldn't.
To fix this, we have a pair of wrappers for getpwnam and getpwuid.
When a real call to getpwnam or getpwuid fails, they fall back to a
cached value, if the uid/gid matches.
(Granting access to /etc/passwd isn't possible with the way we
handle opening files through the sandbox. It's not desirable either.)
On OpenBSD 5.4, time_t is a 32-bit integer. These instances contain
implicit treatment of long and time_t as comparable types, so explicitly
cast to time_t.
Clients should always believe that v3 directory authorities serve
extra-info documents, regardless of whether their server descriptor
contains a "caches-extra-info" line or not.
Fixes part of #11683.
on #9686, gmorehose reports that the 500 MB lower limit is too high
for raspberry pi users.
This is a backport of 647248729f to 0.2.4.
Note that in 0.2.4, the option is called MaxMemInCellQueues.
This was previously satisfied by using a temporary variable, but there
are three other instances in circuitlist.c that gcc is now bothered by,
so now introduce a CONST_TO_ORIGIN_CIRCUIT that takes a const
circuit_t instead.
When clearing a list of tokens, it's important to do token_clear()
on them first, or else any keys they contain will leak. This didn't
leak memory on any of the successful microdescriptor parsing paths,
but it does leak on some failing paths when the failure happens
during tokenization.
Fixes bug 11618; bugfix on 0.2.2.6-alpha.
If we can't detect the physical memory, the new default is 8 GB on
64-bit architectures, and 1 GB on 32-bit architectures.
If we *can* detect the physical memory, the new default is
CLAMP(256 MB, phys_mem * 0.75, MAX_DFLT)
where MAX_DFLT is 8 GB on 64-bit architectures and 2 GB on 32-bit
architectures.
You can still override the default by hand. The logic here is simply
trying to choose a lower default value on systems with less than 12 GB
of physical RAM.
Use a per-channel ratelim_t to control the rate at which we report
failures for each channel.
Explain why I picked N=32.
Never return a zero circID.
Thanks to Andrea and to cypherpunks.
Instead of taking the length of a buffer, we were taking the length of
a pointer, so that our debugging log would cover only the first
sizeof(void*) bytes of the client nonce.
If 'intro' is NULL in these functions, I'm pretty sure that the
error message must be set before we hit the end. But scan-build
doesn't notice that, and is worried that we'll do a null-pointer
dereference in the last-chance errormsg generation.
As it stands, it relies on the fact that onion_queue_entry_remove
will magically remove each onionskin from the right list. This
patch changes the logic to be more resilient to possible bugs in
onion_queue_entry_remove, and less confusing to static analysis tools.
scan-build doesn't realize that a request can't be timed at the end
unless it's timed at the start, and so it's not possible for us to
be subtracting start from end without start being set.
Nevertheless, let's not confuse it.
When get_proxy_addrport returned PROXY_NONE, it would leave
addr/port unset. This is inconsistent, and could (if we used the
function in a stupid way) lead to undefined behavior. Bugfix on
5b050a9b0, though I don't think it affects tor-as-it-is.
Throughout circuituse, when we log about a circuit, we log its
desired path length from build_state. scan-build is irrationally
concerned that build_state might be NULL.
In circuitmux_detach_all_circuits, we check whether an HT iterator
gives us NULL. That should be impossible for an HT iterator. But
our checking it has confused scan-build (justly) into thinking that
our later use of HT_NEXT_RMV might not be kosher. I'm taking the
coward's route here and strengthening the check. Bugfix on
fd31dd44. (Not a real bug though)
If we fail in circuit_get_by_rend_token_and_purpose because the
circuit has no rend_info, don't try to reference fiends from its
rend_info when logging an error. Bugfix on 8b9a2cb68, which is
going into Tor 0.2.5.4-alpha.
Fixes a possible root cause of 11553 by only making 64 attempts at
most to pick a circuitID. Previously, we would test every possible
circuit ID until we found one or ran out.
This algorithm succeeds probabilistically. As the comment says:
This potentially causes us to give up early if our circuit ID
space is nearly full. If we have N circuit IDs in use, then we
will reject a new circuit with probability (N / max_range) ^
MAX_CIRCID_ATTEMPTS. This means that in practice, a few percent
of our circuit ID capacity will go unused.
The alternative here, though, is to do a linear search over the
whole circuit ID space every time we extend a circuit, which is
not so great either.
This makes new vs old clients distinguishable, so we should try to
batch it with other patches that do that, like 11438.
This means that tor can run without needing to communicate with ioctls
to the firewall, and therefore doesn't need to run with privileges to
open the /dev/pf device node.
A new TransProxyType is added for this purpose, "pf-divert"; if the user
specifies this TransProxyType in their torrc, then the pf device node is
never opened and the connection destination is determined with getsockname
(as per pf(4)). The default behaviour (ie., when TransProxyType is "default"
when using the pf firewall) is still to assume that pf is configured with
rdr-to rules.
This isn't on by default; to get it, you need to set "TransProxyType
ipfw". (The original patch had automatic detection for whether
/dev/pf is present and openable, but that seems marginally fragile.)
Libevent uses an arc4random implementation (I know, I know) to
generate DNS transaction IDs and capitalization. But it liked to
initialize it either with opening /dev/urandom (which won't work
under the sandbox if it doesn't use the right pointer), or with
sysctl({CTL_KERN,KERN_RANDOM,RANDOM_UUIC}). To make _that_ work, we
were permitting sysctl unconditionally. That's not such a great
idea.
Instead, we try to initialize the libevent PRNG _before_ installing
the sandbox, and make sysctl always fail with EPERM under the
sandbox.
Appearently, the majority of the filenames we pass to
sandbox_cfg_allow() functions are "freeable right after". So, consider
_all_ of them safe-to-steal, and add a tor_strdup() in the few cases
that aren't.
(Maybe buggy; revise when I can test.)
(If we don't restrict rename, there's not much point in restricting
open, since an attacker could always use rename to make us open
whatever they want.)
