Allow fallback directories which have been stable for 7 days
to work around #18050, which causes relays to submit descriptors
with 0 DirPorts when restarted. (Particularly during Tor version
upgrades.)
Ignore low fallback directory count in alpha builds.
Set the target count to 50.
This is in accordance with our usual policy against freelists,
now that working allocators are everywhere.
It should also make memarea.c's coverage higher.
I also doubt that this code ever helped performance.
Previously, I had left in some debugging code with /*XXX*/ after it,
which nobody noticed. Live and learn! Next time I will use /*XXX
DO NOT COMMIT*/ or something.
We need to define a new consensus method for this; consensus method
21 shouldn't actually be used.
Fixes bug 17702; bugfix on 0.2.7.2-alpha.
We already write out bootstrapping progress (see bug 9927) per new
microdesc batch. There's no need to do a full "I learned some more
directory information, but not enough to..." line each time too.
Now, when a user who has set EntryNodes finishes bootstrapping, Tor
automatically repopulates the guard set based on this new directory
information. Fixes bug 16825; bugfix on 0.2.3.1-alpha.
Originally it can overflow in some weird cases. Now it should no longer
be able to do so.
Additionally, limit main's timers to 30 days rather than to 38 years;
we don't actually want any 38-year timers.
Closes bug 17682.
They are no longer "all" digests, but only the "common" digests.
Part of 17795.
This is an automated patch I made with a couple of perl one-liners:
perl -i -pe 's/crypto_digest_all/crypto_common_digests/g;' src/*/*.[ch]
perl -i -pe 's/\bdigests_t\b/common_digests_t/g;' src/*/*.[ch]
If unix socket was configured as listener (such as a ControlSocket or a
SocksPort unix socket), and tor was started as root but not configured
to switch to another user, tor would segfault while trying to string
compare a NULL value. Fixes bug 18261; bugfix on 0.2.8.1-alpha. Patch
by weasel.
When ClientPreferIPv6ORPort is auto, bridges prefer the configured
bridge ORPort address. Otherwise, they use the value of the option.
Other clients prefer IPv4 ORPorts if ClientPreferIPv6ORPort is auto.
When ClientPreferIPv6DirPort is auto, all clients prefer IPv4 DirPorts.
Modify callers to correctly handle these new NULL returns:
* fix assert in onion_extend_cpath
* warn and discard circuit in circuit_get_open_circ_or_launch
* warn, discard circuit, and tell controller in handle_control_extendcircuit
Bridge clients ignore ClientUseIPv6, acting as if it is always 1.
This preserves existing behaviour.
Make ClientPreferIPv6OR/DirPort auto by default:
* Bridge clients prefer IPv6 by default.
* Other clients prefer IPv4 by default.
This preserves existing behaviour.
ClientUseIPv4 0 tells tor to avoid IPv4 client connections.
ClientPreferIPv6DirPort 1 tells tor to prefer IPv6 directory connections.
Refactor policy for IPv4/IPv6 preferences.
Fix a bug where node->ipv6_preferred could become stale if
ClientPreferIPv6ORPort was changed after the consensus was loaded.
Update documentation, existing code, add unit tests.
node_get_all_orports and router_get_all_orports incorrectly used or_port
with IPv6 addresses. They now use ipv6_orport.
Also refactor and remove duplicated code.
Avoid using a pronoun where it makes comments unclear.
Avoid using gender for things that don't have it.
Avoid assigning gender to people unnecessarily.
Allow fallback directories which have been stable for 30 days
to work around #18050, which causes relays to submit descriptors
with 0 DirPorts when restarted. (Particularly during Tor version
upgrades.)
Ignore low fallback directory count in alpha builds.
Otherwise, relays publish a descriptor with DirPort 0 when the DirPort
reachability test takes longer than the ORPort reachability test.
Closes bug #18050. Reported by "starlight", patch by "teor".
Bugfix on 0.1.0.1-rc, commit a1f1fa6ab on 27 Feb 2005.
* DIGEST_SHA3_[256,512] added as supported algorithms, which do
exactly what is said on the tin.
* test/bench now benchmarks all of the supported digest algorithms,
so it's possible to see just how slow SHA-3 is, though the message
sizes could probably use tweaking since this is very dependent on
the message size vs the SHA-3 rate.
This will give relay operators the ability of disabling the caching of
directory data. In general, this should not be necessary, but on some
lower-resource systems it may beneficial.
I believe that the final SMARTLIST_DEL_CURRENT was sometimes
double-removing items that had already been removed by
connection_mark_unattached_ap or
connection_ap_handshake_attach_circuit().
The fix here is to prevent iteration over the list that other
functions might be modifying.
According to the POSIX standard the option value is a pointer to void
and the option length a socklen_t. The Windows implementation makes the
option value be a pointer to character and the option length an int.
Casting the option value to a pointer to void conforms to the POSIX
standard while the implicit cast to a pointer to character conforms to
the Windows implementation.
The casts of the option length to the socklen_t data type conforms to
the POSIX standard. The socklen_t data type is actually an alias of an
int so it also conforms to the Windows implementation.
It is AP-specific, so that's where it belongs. This shouldn't have
caused a bug, but due to #17876, we were never actually calling
connection_edge_about_to_close from connection_ap_about_to_close,
causing bug #17874 (aka bug #17752).
When a relay does not have an open directory port but it has an
orport configured and is accepting client connections then it can
now service tunnelled directory requests, too. This was already true
of relays with an dirport configured.
We also conditionally stop advertising this functionality if the
relay is nearing its bandwidth usage limit - same as how dirport
advertisement is determined.
Partial implementation of prop 237, ticket 12538
Applies the 6c443e987d fix to router_pick_directory_server_impl.
6c443e987d applied to directory servers chosen from the consensus,
and was:
"Tweak the 9969 fix a little
If we have busy nodes and excluded nodes, then don't retry with the
excluded ones enabled. Instead, wait for the busy ones to be nonbusy."
These IPv6 addresses must be quoted, because : is the port separator,
and "acce" is a valid hex block.
Add unit tests for assumed actions in IPv6 policies.
"Tor has included a feature to fetch the initial consensus from nodes
other than the authorities for a while now. We just haven't shipped a
list of alternate locations for clients to go to yet.
Reasons why we might want to ship tor with a list of additional places
where clients can find the consensus is that it makes authority
reachability and BW less important.
We want them to have been around and using their current key, address,
and port for a while now (120 days), and have been running, a guard,
and a v2 directory mirror for most of that time."
Features:
* whitelist and blacklist for an opt-in/opt-out trial.
* excludes BadExits, tor versions that aren't recommended, and low
consensus weight directory mirrors.
* reduces the weighting of Exits to avoid overloading them.
* places limits on the weight of any one fallback.
* includes an IPv6 address and orport for each FallbackDir, as
implemented in #17327. (Tor won't bootstrap using IPv6 fallbacks
until #17840 is merged.)
* generated output includes timestamps & Onionoo URL for traceability.
* unit test ensures that we successfully load all included default
fallback directories.
Closes ticket #15775. Patch by "teor".
OnionOO script by "weasel", "teor", "gsathya", and "karsten".
* The option is now KeepBindCapabilities
* We now warn if the user specifically asked for KeepBindCapabilities
and we can't deliver.
* The unit tests are willing to start.
* Fewer unused-variable warnings.
* More documentation, fewer misspellings.
router_digest_is_fallback_dir returns 1 if the digest is in the
currently loaded list of fallback directories, and 0 otherwise.
This function is for future use.
Once tor is downloading a usable consensus, any other connection
attempts are not needed.
Choose a connection to keep, favouring:
* fallback directories over authorities,
* connections initiated earlier over later connections
Close all other connections downloading a consensus.
Prop210: Add attempt-based connection schedules
Existing tor schedules increment the schedule position on failure,
then retry the connection after the scheduled time.
To make multiple simultaneous connections, we need to increment the
schedule position when making each attempt, then retry a (potentially
simultaneous) connection after the scheduled time.
(Also change find_dl_schedule_and_len to find_dl_schedule, as it no
longer takes or returns len.)
Prop210: Add multiple simultaneous consensus downloads for clients
Make connections on TestingClientBootstrapConsensus*DownloadSchedule,
incrementing the schedule each time the client attempts to connect.
Check if the number of downloads is less than
TestingClientBootstrapConsensusMaxInProgressTries before trying any
more connections.
UseDefaultFallbackDirs enables any hard-coded fallback
directory mirrors. Default is 1, set it to 0 to disable fallbacks.
Implements ticket 17576.
Patch by "teor".
Update the code for IPv6 authorities and fallbacks for function
argument changes.
Update unit tests affected by the function argument changes in
the patch.
Add unit tests for authority and fallback:
* adding via a function
* line parsing
* adding default authorities
(Adding default fallbacks is unit tested in #15775.)
The internal memory allocation and history object counters of the
reputation code can be used to verify the correctness of (part of) the
code. Using these counters revealed an issue where the memory allocation
counter is not decreased when the bandwidth arrays are freed.
A new function ensures the memory allocation counter is decreased when a
bandwidth array is freed.
This commit also removes an unnecessary cast which was found while
working on the code.
* Since the variable is no longer modified, it should be called
'policy' instead of 'dest'. ("Dest" is short for
"destination".)
* Fixed the space issue that dgoulet found on the ticket.
* Fixed the comment a little. (We use the imperative for function
documentation.)
Some functions that use digest maps did not mention that the digests are
expected to have DIGEST_LEN bytes. This lead to buffer over-reads in the
past.
When an HS process an INTRODUCE2 cell, we didn't validate if the IP address
of the rendezvous point was a local address. If it's the case, we end up
wasting resources by trying to extend to a local address which fails since
we do not allow that in circuit_extend().
This commit now rejects a rendezvous point that has a local address once
seen at the hidden service side unless ExtendAllowPrivateAddresses is set.
Fixes#8976
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
There was a dead check when we made sure that an array member of a
struct was non-NULL. Tor has been doing this check since at least
0.2.3, maybe earlier.
Fixes bug 17781.
Previously we'd suppressed the mask-bits field in the output when
formatting a policy if it was >=32. But that should be a >=128 if
we're talking about IPv6.
Since we didn't put these in descriptors, this bug affects only log
messages and controller outputs.
Fix for bug 16056. The code in question was new in 0.2.0, but the
bug was introduced in 0.2.4 when we started supporting IPv6 exits.
port is in host order (addr is tor_addr_t, endianness is abstracted).
addr and port can be different to conn->addr and conn->port if
connecting via a proxy.
Consistently ignore multicast addresses when automatically
generating reject private exit policies.
Closes ticket 17763. Bug fix on 10a6390deb,
not in any released version of Tor. Patch by "teor".
The tor_cert_get_checkable_sig function uses the signing key included in
the certificate (if available) when a separate public key is not given.
When the signature is valid, the tor_cert_checksig function copies the
public key from the checkable structure to the public key field of the
certificate signing key.
In situations where the separate public key is not given but the
certificate includes a signing key, the source and destination pointers
in the copy operation are equal and invoke undefined behavior.
Undefined behaviour is avoided by ensuring both pointers are different.
These functions must really never fail; so have crypto_rand() assert
that it's working okay, and have crypto_seed_rng() demand that
callers check its return value. Also have crypto_seed_rng() check
RAND_status() before returning.
Stop ignoring ExitPolicyRejectPrivate in getinfo
exit-policy/reject-private. Fix a memory leak.
Set ExitPolicyRejectPrivate in the unit tests, and make a mock
function declaration static.
(If we take the branch above this assertion, than we *didn't* have a
v1 handshake. So if we don't take the branch, we did. So if we
reach this assertion, we must be running as a server, since clients
no longer attempt v1 handshakes.)
Fix for bug 17654; bugfix on 9d019a7db7.
Bug not in any released Tor.
Refuse connection requests to private OR addresses unless
ExtendAllowPrivateAddresses is set. Previously, tor would
connect, then refuse to send any cells to a private address.
Fixes bugs 17674 and 8976; bugfix on b7c172c9ec (28 Aug 2012)
Original bug 6710, released in 0.2.3.21-rc and an 0.2.2 maint
release.
Patch by "teor".
This migrates away from SHA1, and provides further hash flooding
protection on top of the randomised siphash implementation.
Add unit tests to make sure that different inputs don't have the
same hash.
The wrong list was used when looking up expired intro points in a rend
service object causing what we think could be reachability issues and
triggering a BUG log.
Fixes#16702
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
exit-policy/reject-private lists the reject rules added by
ExitPolicyRejectPrivate. This makes it easier for stem to
display exit policies.
Add unit tests for getinfo exit-policy/*.
Completes ticket #17183. Patch by "teor".
Modify policies_parse_exit_policy_reject_private so it also blocks
the addresses configured for OutboundBindAddressIPv4_ and
OutboundBindAddressIPv6_, and any publicly routable port addresses
on exit relays.
Add and update unit tests for these functions.
Move the code that rejects publicly routable exit relay addresses
to policies_parse_exit_policy_reject_private. Add
addr_policy_append_reject_addr_list and use it to reject interface
addresses.
This removes the duplicate reject checks on local_address and
ipv6_local_address, but duplicates will be removed by
exit_policy_remove_redundancies at the end of the function.
This also removes the info-level logging on rejected interface
addresses. Instead, log a debug-level message in
addr_policy_append_reject_addr.
This simplifies policies_parse_exit_policy_internal and prepares for
reporting these addresses over the control port in #17183.
Loading a on disk bridge descriptor causes a directory download to be
scheduled, which asserts due to the periodic events not being
initialized yet.
Fixes bug #17635, not in any released version of tor.
Now we only re-scan the list in the cases we did before: when we
have a new circuit that we should try attaching to, or when we have
added a new stream that we haven't tried to attach yet.
This is part of 17590.
Long ago we used to call connection_ap_handshake_attach_circuit()
only in a few places, since connection_ap_attach_pending() attaches
all the pending connections, and does so regularly. But this turned
out to have a performance problem: it would introduce a delay to
launching or connecting a stream.
We couldn't just call connection_ap_attach_pending() every time we
make a new connection, since it walks the whole connection list. So
we started calling connection_ap_attach_pending all over, instead!
But that's kind of ugly and messes up our callgraph.
So instead, we now have connection_ap_attach_pending() use a list
only of the pending connections, so we can call it much more
frequently. We have a separate function to scan the whole
connection array to see if we missed adding anything, and log a
warning if so.
Closes ticket #17590
Mark fallback directory mirrors as "too busy" when they return
a 503 response. Previously, the code just marked authorities as busy.
Unless clients set their own fallback directories, they will never see
this bug. (There are no default fallbacks yet.)
Fixes bug 17572; bugfix on 5c51b3f1f0 released in 0.2.4.7-alpha.
Patch by "teor".
When logging to syslog, allow a tag to be added to the syslog identity
("Tor"), i.e. the string prepended to every log message. The tag can be
configured by setting SyslogIdentityTag and defaults to none. Setting
it to "foo" will cause logs to be tagged as "Tor-foo". Closes: #17194.
Warn when the state file was last written in the future.
Tor doesn't know that consensuses have expired if the clock is in the past.
Patch by "teor". Implements ticket #17188.
BSD make takes spaces around = literally
and produces a "TESTING_TOR_BINARY "
variable with a trailing space, which leads
to test_keygen.sh failure.
Fixes 17154
When we find a conflict in the keypinning journal, treat the new
entry as superseding all old entries that overlap either of its
keys.
Also add a (not-yet-used) configuration option to disable keypinning
enforcement.
src/test/test_policy.c:
Merged calls to policies_parse_exit_policy by adding additional arguments.
fixup to remaining instance of ~EXIT_POLICY_IPV6_ENABLED.
Compacting logic test now produces previous list length of 4, corrected this.
src/config/torrc.sample.in:
src/config/torrc.minimal.in-staging:
Merged torrc modification dates in favour of latest.
Log an info-level message containing the reject line added to the
exit policy for each local IP address blocked by ExitPolicyRejectPrivate:
- Published IPv4 and IPv6 addresses
- Publicly routable IPv4 and IPv6 interface addresses
ExitPolicyRejectPrivate now rejects more local addresses by default:
* the relay's published IPv6 address (if any), and
* any publicly routable IPv4 or IPv6 addresses on any local interfaces.
This resolves a security issue for IPv6 Exits and multihomed Exits that
trust connections originating from localhost.
Resolves ticket 17027. Patch by "teor".
Patch on 42b8fb5a15 (11 Nov 2007), released in 0.2.0.11-alpha.
In previous versions of Tor, ExitPolicy accept6/reject6 * produced
policy entries for IPv4 and IPv6 wildcard addresses.
To reduce operator confusion, change accept6/reject6 * to only produce
an IPv6 wildcard address.
Resolves bug #16069.
Patch on 2eb7eafc9d and a96c0affcb (25 Oct 2012),
released in 0.2.4.7-alpha.
Tor now warns when ExitPolicy lines occur after accept/reject *:*
or variants. These lines are redundant, and were always ignored.
Partial fix for ticket 16069. Patch by "teor".
Patch on 2eb7eafc9d and a96c0affcb (25 Oct 2012),
released in 0.2.4.7-alpha.
When parsing torrc ExitPolicies, we now warn if:
* an IPv4 address is used on an accept6 or reject6 line. The line is
ignored, but the rest of the policy items in the list are used.
(accept/reject continue to allow both IPv4 and IPv6 addresses in torrcs.)
* a "private" address alias is used on an accept6 or reject6 line.
The line filters both IPv4 and IPv6 private addresses, disregarding
the 6 in accept6/reject6.
When parsing torrc ExitPolicies, we now issue an info-level message:
* when expanding an accept/reject * line to include both IPv4 and IPv6
wildcard addresses.
In each instance, usage advice is provided to avoid the message.
Partial fix for ticket 16069. Patch by "teor".
Patch on 2eb7eafc9d and a96c0affcb (25 Oct 2012),
released in 0.2.4.7-alpha.
routerset_parse now accepts IPv6 literal addresses.
Fix for ticket 17060. Patch by "teor".
Patch on 3ce6e2fba2 (24 Jul 2008), and related commits,
released in 0.2.1.3-alpha.
When validating a new descriptor against our rend cache failure, we were
added the failure entry to the new cache entry without duplicating. It was
then freed just after the validation ending up in a very bad memory state
that was making tor abort(). To fix this, a dup function has been added and
used just before adding the failure entry.
Fixes#17041
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
No functional changes, but since NoKeepAliveIsolateSOCKSAuth isn't
part of isoflag, it should be checked where all other similar options
are, and bypass the (no-op) masking at the end.
This controls the circuit dirtyness reset behavior added for Tor
Browser's user experience fix (#15482). Unlike previous iterations
of this patch, the tunable actually works, and is documented.
Performing lookups in both the client and service side descriptor
caches from the same rend_cache_lookup_entry() function increases the
risk of accidental API misuse.
I'm separating the lookup functions to keep the caches distinct.
Parameterize the rend_cache_clean() function to allow it clean
old rendezvous descriptors from the service-side cache as well as
the client descriptor cache.
Including the replica number in the HS_DESC CREATED event provides
more context to a control port client. The replica allows clients
to more easily identify each replicated descriptor from the
independantly output control events.
Entries in the service-side descriptor cache are now cleaned when
rend_cache_free_all() is called. The call to tor_free(intro_content)
in rend_cache_store_v2_desc_as_service() is moved to prevent a
potential double-free when a service has a descriptor with a newer
timestamp already in it's service-side descriptor cache.
Adds an Enum which represents the different types of rendezvous
descriptor caches. This argument is passed in each call to
rend_cache_lookup_entry() to specify lookup in the client-side or
service-side descriptor caches.
Adds a control command to fetch a local service descriptor from the
service descriptor cache. The local service descriptor cache is
referenced by the onion address of the service.
This control command is documented in the control spec.
When this is set, and Tor is running as a relay, it will not
generate or load its secret identity key. You can manage the secret
identity key with --keygen. Implements ticket 16944.
In a nutshell, since a circuit can not exit at its entry point, it's very
easy for an attacker to find the hidden service guard if only one EntryNodes
is specified since for that guard, the HS will refuse to build a rendezvous
circuit to it.
For now, the best solution is to stop tor to allow a single EntryNodes for
an hidden service.
Fixes#14917
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
Only applies to connections with SOCKS auth set, so that non-web Tor
activity is not affected.
Simpler version of Nick's patch because the randomness worried me, and I'm not
otherwise sure why we want a max here.
In validate_recommended_package_line, at this point in the function,
n_entries is always >= 1. Coverity doesn't like us checking it for
0.
CID 1268063.
Removes a check to PublishHidServDescriptors in
rend_consider_services_upload(). This allows descriptors to be
generated and stored in the local cache when PublishHidServDescriptor = 0.
Keep the PublishHidServDescriptors option check in
rend_consider_descriptor_republication(). We will never need to republish
a descriptor if we are not publishing descriptors to the HSDirs.
Service descriptors are now generated regardless of the the
PublishHidServDescriptors option. The generated descriptors are stored
in the service descriptor cache.
The PublishHidServDescriptors = 1 option now prevents descriptor
publication to the HSDirs rather than descriptor generation.
Deindent a block of code inside the PublishHidServDescriptors option
check in upload_service_descriptor(). Stylistic commit to make the
subsequent reworking of this code cleaner.
The HS_DESC CREATED event should be emmited when a new service descriptor
is generated for a local rendevous service. This event is documented
in the control spec.
This commit resolves ticket #16291.
Adds a service descriptor cache which is indexed by service ID. This
descriptor cache is used to store service descriptors generated by a
local rendevous service.
The service-side cach can be queried by calling rend_cache_lookup_entry()
with the 'service' argument set to 1.
We used to use this when we had some controllers that would accept
long names and some that wouldn't. But it's been obsolete for a
while, and it's time to strip it out of the code.
Previously we'd put these strings right on the controllers'
outbufs. But this could cause some trouble, for these reasons:
1) Calling the network stack directly here would make a huge portion
of our networking code (from which so much of the rest of Tor is
reachable) reachable from everything that potentially generated
controller events.
2) Since _some_ events (EVENT_ERR for instance) would cause us to
call connection_flush(), every control_event_* function would
appear to be able to reach even _more_ of the network stack in
our cllgraph.
3) Every time we generated an event, we'd have to walk the whole
connection list, which isn't exactly fast.
This is an attempt to break down the "blob" described in
http://archives.seul.org/tor/dev/Mar-2015/msg00197.html -- the set of
functions from which nearly all the other functions in Tor are
reachable.
Closes ticket 16695.
Make it easier to unit test TestingDirAuthVote{Exit,Guard,HSDir}
by refactoring the code which sets flags based on them into a
new function dirserv_set_routerstatus_testing.
"option to prevent guard,exit,hsdir flag assignment"
"A node will never receive the corresponding flag unless
that node is specified in the
TestingDirAuthVote{Exit,Guard,HSDir} list, regardless of
its uptime, bandwidth, exit policy, or DirPort".
Patch modified by "teor": VoteOnHidServDirectoriesV2
is now obsolete, so TestingDirAuthVoteHSDir always
votes on HSDirs.
Closes ticket 14882. Patch by "robgjansen".
Commit message and changes file by "teor"
with quotes from "robgjansen".
Fix an error in the manual page and comments for
TestingDirAuthVoteHSDir, which suggested that a
HSDir required "ORPort connectivity". While this is true,
it is in no way unique to the HSDir flag. Of all the flags,
only HSDirs need a DirPort configured in order for the
authorities to assign that particular flag.
Fixed as part of 14882. Patch by "teor".
Bugfix on 0.2.6.3 (f9d57473e1 on 10 January 2015).
* FIXES#16823: https://bugs.torproject.org/16823
If an OP were to send a CREATE_FAST cell to an OR, and that
CREATE_FAST cell had unparseable key material, then tor_free() would
be called on the create cell twice. This fix removes the second
(conditional on the key material being bad) call to tor_free(), so
that now the create cell is always freed once, regardless of the status of
the key material.
(This isn't actually a double-free bug, since tor_free() sets its
input to NULL, and has no effect when called with input NULL.)
Instead of having it call update_all_descriptor_downloads and
update_networkstatus_downloads directly, we can have it cause them to
get rescheduled and called from run_scheduled_events.
Closes ticket 16789.
When fetching a descriptor, we know test every introduction points in it
against our rend failure cache to know if we keep it or not. For this to
work, now everytime an introduction points is discareded (ex: receiving a
NACK), we note it down in our introduction cache.
See rendcache.c for a detailed explanation of the cache's behavior.
Fixes#16389
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
When we removed Running/Valid checks from Fast and Stable in 8712, I
removed them from HSDir too, which apparently wasn't a good idea.
Reverts part of a65e835800. Fixes bug 16524. Bugfix
on 0.2.7.2-alpha.
microdesc_free_() called get_microdesc_cache(), which had the fun
side-effect of potentially reloading the whole cache from disk.
Replace it with a variant that doesn't.
The base64 and base32 functions used to be in crypto.c;
crypto_format.h had no header; some general-purpose functions were in
crypto_curve25519.c.
This patch makes a {crypto,util}_format.[ch], and puts more functions
there. Small modules are beautiful!
The control port was using set_max_file_descriptors() with a limit set to 0
to query the number of maximum socket Tor can use. With the recent changes
to that function, a check was introduced to make sure a user can not set a
value below the amount we reserved for non socket.
This commit adds get_max_sockets() that returns the value of max_sockets so
we can stop using that "setter" function to get the current value.
Finally, the dead code is removed that is the code that checked for limit
equal to 0. From now on, set_max_file_descriptors() should never be used
with a limit set to 0 for a valid use case.
Fixes#16697
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
1) We already require C99.
2) This allows us to support MSVC again (thanks to Gisle Vanem for
this part)
3) This change allows us to dump some rotten old compatibility code
from log.c
Make sure that signing certs are signed by the right identity key,
to prevent a recurrence of #16530. Also make sure that the master
identity key we find on disk matches the one we have in RAM, if we
have one.
This is for #16581.
When there is a signing key and the certificate lists a key, make
sure that the certificate lists the same signing key.
When there are public key and secret key stored in separate files,
make sure they match.
Use the right file name when we load an encrypted secret key and
then find a problem with it.
This is part of 16581.
When cleaning up extra circuits that we've opened for performance reason, we
need to count all the introduction circuit and not only the established ones
else we can end up with too many introduction points.
This also adds the check for expiring nodes when serving an INTRODUCE cell
since it's possible old clients are still using them before we have time to
close them.
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
To upload a HS descriptor, this commits makes it that we wait for all
introduction point to be fully established.
Else, the HS ends up uploading a descriptor that may contain intro points
that are not yet "valid" meaning not yet established or proven to work. It
could also trigger three uploads for the *same* descriptor if every intro
points takes more than 30 seconds to establish because of desc_is_dirty
being set at each intro established.
To achieve that, n_intro_points_established varialbe is added to the
rend_service_t object that is incremented when we established introduction
point and decremented when we remove a valid intro point from our list.
The condition to upload a descriptor also changes to test if all intro
points are ready by making sure we have equal or more wanted intro points
that are ready.
The desc_id_dirty flag is kept to be able to still use the
RendInitialPostPeriod option.
This partially fixes#13483.
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
There is a case where if the introduction circuit fails but the node is
still in the consensus, we clean up the intro point and choose an other one.
This commit fixes that by trying to reuse the existing intro point with a
maximum value of retry.
A retry_nodes list is added to rend_services_introduce() and when we remove
an invalid intro points that fits the use case mentionned before, we add the
node to the retry list instead of removing it. Then, we retry on them before
creating new ones.
This means that the requirement to remove an intro point changes from "if no
intro circuit" to "if no intro circuit then if no node OR we've reached our
maximum circuit creation count".
For now, the maximum retries is set to 3 which it completely arbitrary. It
should also at some point be tied to the work done on detecting if our
network is down or not.
Fixes#8239
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
The reasoning for refactoring this function is that removing the
introduction point adaptative algorithm (#4862) ended up changing quite a
bit rend_services_introduce(). Also, to fix some open issues (#8239, #8864
and #13483), this work had to be done.
First, this removes time_expiring variable in an intro point object and
INTRO_POINT_EXPIRATION_GRACE_PERIOD trickery and use an expiring_nodes list
where intro nodes that should expire are moved to that list and cleaned up
only once the new descriptor is successfully uploaded. The previous scheme
was adding complexity and arbitrary timing to when we expire an intro point.
We keep the intro points until we are sure that the new descriptor is
uploaded and thus ready to be used by clients. For this,
rend_service_desc_has_uploaded() is added to notify the HS subsystem that
the descriptor has been successfully uploaded. The purpose of this function
is to cleanup the expiring nodes and circuits if any.
Secondly, this adds the remove_invalid_intro_points() function in order to
split up rend_services_introduce() a bit with an extra modification to it
that fixes#8864. We do NOT close the circuit nor delete the intro point if
the circuit is still alive but the node was removed from the consensus. Due
to possible information leak, we let the circuit and intro point object
expire instead.
Finally, the whole code flow is simplified and large amount of documentation
has been added to mostly explain the why of things in there.
Fixes#8864
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
This is a way to specify the amount of introduction points an hidden service
can have. Maximum value is 10 and the default is 3.
Fixes#4862
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
When we ran out of intro points for a hidden service (which could
happen on a newnym), we would change the connection's state back to
"waiting for hidden service descriptor." But this would make an
assertion fail if we went on to call circuit_get_open_circ_or_launch
again.
This fixes bug 16013; I believe the bug was introduced in
38be533c69, where we made it possible for
circuit_get_open_circ_or_launch() to change the connection's state.
When I fixed#11243, I made it so we would take the digest of a
descriptor before tokenizing it, so we could desist from download
attempts if parsing failed. But when I did that, I didn't remove an
assertion that the descriptor began with "onion-key". Usually, this
was enforced by "find_start_of_next_microdescriptor", but when
find_start_of_next_microdescriptor returned NULL, the assertion was
triggered.
Fixes bug 16400. Thanks to torkeln for reporting and
cypherpunks_backup for diagnosing and writing the first fix here.
Every functions and objects that are used for hidden service descriptor
caches are moved to rendcache.{c|h}.
This commit does NOT change anything, just moving code around.
Fixes#16399
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
For now, rend_cache_entry_t has been moved from or.h to rendcache.h and
those files have been added to the build system.
In the next commit, these will contain hidden service descriptor cache ABI
and API for both client and directory side. The goal is to consolidate the
descriptor caches in one location to ease development, maintenance, review
and improve documentation for each cache behavior and algorithm.
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
When --keygen is provided, we prompt for a passphrase when we make a
new master key; if it is nonempty, we store the secret key in a new
crypto_pwbox.
Also, if --keygen is provided and there *is* an encrypted master key,
we load it and prompt for a passphrase unconditionally.
We make a new signing key unconditionally when --keygen is provided.
We never overwrite a master key.
If crypto_early_init fails, a typo in a return value from tor_init
means that tor_main continues running, rather than returning
an error value.
Fixes bug 16360; bugfix on d3fb846d8c in 0.2.5.2-alpha,
introduced when implementing #4900.
Patch by "teor".
This reverts commit 9407040c59.
Small fix, "e->received" had to be removed since that variable doesn't exist
anymore.
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
signing_key can be NULL in ed_key_init_from_file in routerkeys.c.
Discovered by clang 3.7 address sanitizer.
Fix on c03694938e, not in any released version of Tor.
Rend_add_service() frees its argument on failure; no need to free again.
Fixes bug 16228, bugfix on 0.2.7.1-alpha
Found by coverity; this is CID 1301387.
Also, have testing-level options to set the lifetimes and
expiration-tolerances of all key types, plus a non-testing-level
option to set the lifetime of any auto-generated signing key.
# The first commit's message is:
Regenerate ed25519 keys when they will expire soon.
Also, have testing-level options to set the lifetimes and
expiration-tolerances of all key types, plus a non-testing-level
option to set the lifetime of any auto-generated signing key.
# The 2nd commit message will be skipped:
# fixup! Regenerate ed25519 keys when they will expire soon.
This is a new collator type that follows proposal 220 for deciding
which identities to include. The rule is (approximately):
If a <ed,rsa> identity is listed by more than half of authorities,
include it. And include all <rsa> votes about that node as
matching.
Otherwise, if an <*,rsa> or <rsa> identity is listed by more than
half of the authorities, and no <ed,rsa> has been listed, include
it.
* Include ed25519 identities in votes
* Include "no ed25519 identity" in votes
* Include some commented-out code about identity voting. (This
will disappear.)
* Include some functions for identity voting (These will disappear.)
* Enforce uniqueness in ed25519 keys within a vote
Extrainfo documents are now ed-signed just as are router
descriptors, according to proposal 220. This patch also includes
some more tests for successful/failing parsing, and fixes a crash
bug in ed25519 descriptor parsing.
An earlier version of these tests was broken; now they're a nicer,
more robust, more black-box set of tests. The key is to have each
test check a handshake message that is wrong in _one_ way.
When there are annotations on a router descriptor, the
ed25519-identity element won't be at position 0 or 1; it will be at
router+1 or router-1.
This patch also adds a missing smartlist function to search a list for
an item with a particular pointer.
With this patch:
* Authorities load the key-pinning log at startup.
* Authorities open a key-pinning log for writing at startup.
* Authorities reject any router with an ed25519 key where they have
previously seen that ed25519 key with a different RSA key, or vice
versa.
* Authorities warn about, but *do not* reject, RSA-only descriptors
when the RSA key has previously gone along with an Ed25519 key.
(We should make this a 'reject' too, but we can't do that until we're
sure there's no legit reason to downgrade to 0.2.5.)
This module implements a key-pinning mechanism to ensure that it's
safe to use RSA keys as identitifers even as we migrate to Ed25519
keys. It remembers, for every Ed25519 key we've seen, what the
associated Ed25519 key is. This way, if we see a different Ed25519
key with that RSA key, we'll know that there's a mismatch.
We persist these entries to disk using a simple format, where each
line has a base64-encoded RSA SHA1 hash, then a base64-endoded
Ed25519 key. Empty lines, misformed lines, and lines beginning with
a # are ignored. Lines beginning with @ are reserved for future
extensions.
Routers now use TAP and ntor onion keys to sign their identity keys,
and put these signatures in their descriptors. That allows other
parties to be confident that the onion keys are indeed controlled by
the router that generated the descriptor.
Routers now use TAP and ntor onion keys to sign their identity keys,
and put these signatures in their descriptors. That allows other
parties to be confident that the onion keys are indeed controlled by
the router that generated the descriptor.
For prop220, we have a new ed25519 certificate type. This patch
implements the code to create, parse, and validate those, along with
code for routers to maintain their own sets of certificates and
keys. (Some parts of master identity key encryption are done, but
the implementation of that isn't finished)
As OpenSSL >= 1.0.0 is now required, ECDHE is now mandatory. The group
has to be validated at runtime, because of RedHat lawyers (P224 support
is entirely missing in the OpenSSL RPM, but P256 is present and is the
default).
Resolves ticket #16140.
When set, this limits the maximum number of simultaneous streams per
rendezvous circuit on the server side of a HS, with further RELAY_BEGIN
cells being silently ignored.
This can be modified via "HiddenServiceMaxStreamsCloseCircuit", which
if set will cause offending rendezvous circuits to be torn down instead.
Addresses part of #16052.
Ephemeral services will be listed in rend_services_list at the end of
rend_config_services, so it must check whether directory is non-NULL
before comparing.
This crash happens when reloading config on a tor with mixed configured
and ephemeral services.
Fixes bug #16060. Bugfix on 0.2.7.1-alpha.
For FAILED and RECEIVED action of the HS_DESC event, we now sends back the
descriptor ID at the end like specified in the control-spec section 4.1.25.
Fixes#15881
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
The length of auth_data from an INTRODUCE2 cell is checked when the
auth_type is recognized (1 or 2), but not for any other non-zero
auth_type. Later, auth_data is assumed to have at least
REND_DESC_COOKIE_LEN bytes, leading to a client-triggered out of bounds
read.
Fixed by checking auth_len before comparing the descriptor cookie
against known clients.
Fixes#15823; bugfix on 0.2.1.6-alpha.
"+HSPOST" and the related event changes allow the uploading of HS
descriptors via the control port, and more comprehensive event
monitoring of HS descriptor upload status.
When we have a new descriptor ID for an onion address request, change it in
the rend_data_t object and purge the old one from the last hid serv request
cache.
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
Stop using an onion address since it's not indexed with that anymore in the
last hid serv request cache. Instead use a base32 encoded descriptor ID
contained in the rend_data_t object.
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
Every callsite that use to allocate a rend_data_t object now use the
rend_data_client/service_create() function.
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
Ground works for fixing #15816. This adds the rend_data_create() function in
order to have a single place where we initialize that data structure.
Furthermore, an array of descriptor IDs is added (one per replica) so we can
keep a copy of the current id in the object. It will be used to purge the
last hid serv request cache using those descriptor IDs. When they change,
they will be replaced and the old ones will be purged from the cache.
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
Fixes#15850, part of #15801. Change file is added by this commit. The
original comment in the reverted commit is removed because right now we
*need* a DirPort until #15849 is implemented so no doubt nor confusion there
anymore.
This reverts commit 80bed1ac96.
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
These commands allow for the creation and management of ephemeral
Onion ("Hidden") services that are either bound to the lifetime of
the originating control connection, or optionally the lifetime of
the tor instance.
Implements #6411.
The "longest possible policy" comment in
router_parse_addr_policy_item_from_string() used an example policy
that was actually shorter than the maximum length.
This comment was amended, and expanded to count the maximum number of
characters.
Comment change only.
Unit tests for the 10 valid combinations of set/NULL config options
DirAuthorities, AlternateBridgeAuthority, AlternateDirAuthority,
and FallbackDir.
Add assertion in consider_adding_dir_servers() for checks in
validate_dir_servers():
"You cannot set both DirAuthority and Alternate*Authority."
Only add the default fallback directories when the DirAuthorities,
AlternateDirAuthority, and FallbackDir directory config options
are set to their defaults.
The default fallback directory list is currently empty, this fix will
only change tor's behaviour when it has default fallback directories.
Fixes bug 15642; bugfix on 90f6071d8d in 0.2.4.7-alpha. Patch by "teor".
When self-testing reachability, use ExtendAllowPrivateAddresses
to determine if local/private addresses imply reachability.
The previous fix used TestingTorNetwork, which implies
ExtendAllowPrivateAddresses, but this excluded rare configs where
ExtendAllowPrivateAddresses is set but TestingTorNetwork is not.
Fixes bug 15771; bugfix on 0.2.6.1-alpha, bug #13924.
Patch by "teor", issue discovered by CJ Ess.
The HS_DESC_CONTENT event results in multiple line thus must be prefixed
with a "650+" and ending with "650 OK".
Reported-by: Damian Johnson <atagar@torproject.org>
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
The HS_DESC event was using rend_data_t from the dir connection to reply the
onion address and authentication type. With the new HSFETCH command, it's
now possible to fetch a descriptor only using the descriptor id thus
resulting in not having an onion address in any HS_DESC event.
This patch removes rend_query from the hs desc control functions and replace
it by an onion address string and an auth type.
On a successful fetch, the service id is taken from the fetched descriptor.
For that, an extra parameter is added to "store as a client" function that
contains the cache entry stored.
This will make the control event functions scale more easily over time if
other values not present in rend_data_t are needed since the rend_data from
the dir connection might not contained everything we need.
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
Big refactor of the HS client descriptor fetch functionnality. This allows
to fetch an HS descriptor using only a descriptor ID. Furthermore, it's also
possible to provide a list of HSDir(s) now that are used instead of the
automatically choosen one.
The approach taken was to add a descriptor_id field to the rend_data_t
structure so it can be used, if available, by the HS client. The onion
address field however has priority over it that is if both are set, the
onion address is used to fetch the descriptor.
A new public function is introduced called rend_client_fetch_v2_desc(...)
that does NOT lookup the client cache before fetching and can take a list of
HSDirs as a parameter.
The HSFETCH control command now uses this new function thus making it work
and final.
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
As defined in section 4.1.26 in the control-spec.txt, this new event replies
the content of a successfully fetched HS descriptor. This also adds a unit
test for the controller event.
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
This adds the command on the controller side that parses and validate
arguments but does nothing for now. The HS desriptor fetch must be
modularized a bit more before we can use the command.
See control-spec.txt section 3.26 for more information on this command.
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
Incidently, this fixes a bug where the maximum value was never used when
only using crypto_rand_int(). For instance this example below in
rendservice.c never gets to INTRO_POINT_LIFETIME_MAX_SECONDS.
int intro_point_lifetime_seconds =
INTRO_POINT_LIFETIME_MIN_SECONDS +
crypto_rand_int(INTRO_POINT_LIFETIME_MAX_SECONDS -
INTRO_POINT_LIFETIME_MIN_SECONDS);
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
An introduction point is currently rotated when the amount of INTRODUCE2
cells reached a fixed value of 16384. This makes it pretty easy for an
attacker to inflate that number and observe when the IP rotates which leaks
the popularity of the HS (amount of client that passed through the IP).
This commit makes it a random count between the current value of 16384 and
two times that.
Fixes#15745
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
Background processes spawned by Tor now will have a valid stdin.
Pluggable transports can detect this behavior with the aformentioned
enviornment variable, and exit if stdin ever gets closed.
The rend-spec.txt document doesn't specify this extra newline. Furthermore,
this is the only descryptor type that contains one. Client and HSDir without
this patch still work perfectly since the HS descriptor parsing doesn't
expect a newline at the end.
Fixes#15296
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
Remove src/or/or_sha1.i and src/common/common_sha1.i on `make clean` and remove
the temporary micro-revision file when its no longer needed.
Additional changes;
- show a message when generating the micro-revision file.
- add the temporary micro revision file to the list of files to be removed on
`make clean` just in case.
- fix indentation of the make rule to improve readability.
PTs expect the auth cookie to be available immedieately after launch,
leading to a race condition when PTs opt to cache the extorport cookie
once immediately after startup.
Fixes#15240.
Report errors if the notification fails; report success only if it
succeeds; and if we are not notifying systemd because we aren't
running with systemd, don't log at notice.
We already log whenever our state changes, e.g. whenever new directory
information arrives. This additional log_warn() will at best just add more
log messages, or worse, make the user wonder what she needs to fix.
(Changed after consultation with Yawning.)
Nothing ever uses the string when we're in "have minimum dir info"
state. The flow of the function is "check for problems, if you see a
problem write an explanation to dir_info_status and set res to 0". If
you get to the end of the function without any problems, then res =
1 and we're all ready to start making circuits.
(Changed after consultation with Yawning.)
Parse the file just before voting and apply its information to the
provided vote_routerstatus_t. This follows the same logic as when
dirauths parse bwauth files.
`dir_info_status` is used from main.c:directory_info_has_arrived() to
provide useful (INFO/NOTICE) level logging to users, and should always
be updated regardless of the rate limiting.
This adds the key "hs/client/desc/id/<ADDR>" to the GETINFO command used to
lookup the given onion address in the client hs descriptor cache.
If found, prints it formatted as specified in section 1.3 of rend-spec.txt.
Fixes#14845
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
The idea here is that a controller should be able to make Tor produce a
new relay descriptor on demand, without that descriptor actually being
uploaded to the dirauths (they would likely reject it anyway due to
freshness concerns).
Implements #14784.
Allow building a router descriptor without storing it to global state.
This is in preparation of a patch to export the created descriptors via
the control port.
The issue is that we use the cpuworker system with relays only, so if we
start up as a client and transition to being a relay later, we'll be
sad.
This fixes bug 14901; not in any released version of Tor.
They have been off-by-default since 0.2.5 and nobody has complained. :)
Also remove the buf_shrink() function, which hasn't done anything
since we first stopped using contiguous memory to store buffers.
Closes ticket 14848.
This fixes a bug where we decide to free the circuit because it isn't on
any workqueue anymore, and then the job finishes and the circuit gets
freed again.
Fixes bug #14815, not in any released version of Tor.
like might happen for Tails or Whonix users who start with a very wrong
hardware clock, use Tor to discover a more accurate time, and then
fix their clock.
Resolves part of ticket 8766.
(There are still some timers in various places that aren't addressed yet.)
In #14803, Damian noticed that his Tor sometimes segfaults. Roger noted
that his valgrind gave an invalid write of size one here. Whenever we
use FLEXIBLE_ARRAY_MEMBER, we have to make sure to actually malloc a
thing that's large enough.
Fixes bug #14803, not in any released version of Tor.
If the guard unreachable_since variable was set, the status "up" was
reported which is wrong. This adds the "down" status followed by the
unreachable_since time value.
Fixes#14184
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
David Goulet finds that when he runs a busy relay for a while with the
latest version of the git code, the number of onionskins handled
slowly dwindles to zero, with total_pending_tasks wedged at its
maximum value.
I conjecture this is because the total_pending_tasks variable isn't
decremented when we successfully cancel a job. Fixed that.
Fixes bug 14741; bugfix not on any released version of tor.
Ordinarily, get_options() can never return NULL, but with
test_status.c mocking, it can. So test for that case.
The best fix here would be to pass the options value to a
bridge_server_mode() function.
After connectivity problems, only try connecting to bridges which
are currently configured; don't mark bridges which we previously
used but are no longer configured. Fixes 14216. Reported by
and fix provided by arma.
It's now possible to use SocksPort or any other kind of port that can use a
Unix socket like so:
SocksPort unix:/foo/bar/unix.sock
Fixes#14451
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
Introduces two new circuit status name-value parameters: SOCKS_USERNAME
and SOCKS_PASSWORD. Values are enclosing in quotes and unusual characters
are escaped.
Example:
650 CIRC 5 EXTENDED [...] SOCKS_USERNAME="my_username" SOCKS_PASSWORD="my_password"
Here is why:
1) v0 descriptors are deprecated since 0.2.2.1 and not suppose to be alive
in the network anymore. This function should only serve v2 version for now
as the default.
2) It should return different error code depending on what's the actual
error is. Right now, there is no distinction between a cache entry not found
and an invalid query.
3) This function should NOT test if the intro points are usable or not. This
adds some load on a function that should be "O(1)" and do one job.
Furthermore, multiple callsites actually already test that doing twice the
job...
4) While adding control event, it would be useful to be able to lookup a
cache entry without having it checking the intro points. There are also
places in the code that do want to lookup the cache entry without doing
that.
Fixes#14391
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
Also, do a little light refactoring to move some variable declarations
around and make a few things const
Also fix an obnoxious bug on checking for the DONE stream end reason.
It's not a flag; it's a possible value or a variable that needs to be
masked.
Once a NACK is received on the intro circuit, tor tries an other usable one
by extending the current circuit to it. If no more intro points are usable,
now close the circuit. Also, it's reason is changed before closing it so we
don't report again an intro point failure and trigger an extra HS fetch.
Fixes#14224
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
Once a NACK is received on the intro circuit, tor tries an other usable one
by extending the current circuit to it. If no more intro points are usable,
now close the circuit.
Fixes#14224
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
This fixes a bug where we'd fetch different replicas of the same
descriptor for a down hidden service over and over, until we got lucky
and fetched the same replica twice in a row.
Fixes bug 14219; bugfix on 0.2.0.10-alpha.
(Patch from Roger; commit message and changes file by Nick.)
We've started to hit the limit here. We introduced the limit in
0.1.2.5-alpha. This fixes bug 14261, but we should have a smarter way
to not actually do the behavior this permits. See #14267 for a ticket
about fixing that.
This incidentally makes unix SocksSocket support all the same options
as SocksPort.
This patch breaks 'SocksSocket 0'; next will restore it.
Resolves 14254.
Previously I used one queue per worker; now I use one queue for
everyone. The "broadcast" code is gone, replaced with an idempotent
'update' operation.
The solution I took is to not free a circuit with a pending
uncancellable work item, but rather to set its magic number to a
sentinel value. When we get a work item, we check whether the circuit
has that magic sentinel, and if so, we free it rather than processing
the reply.
To avoid having diffs turn out too big, I had replaced some unneeded
ifs and fors with if (1), so that the indentation would still work out
right. Now I might as well clean those up.
The trick here is to apply mapaddress first, and only then apply
automapping. Otherwise, the automap checks don't get done.
Fix for bug 7555; bugfix on all versions of Tor supporting both
MapAddress and AutoMap.
There were following problems:
- configure.ac wrongly checked for defined HAVE_SYSTEMD; this
wasn't working, so the watchdog code was not compiled in.
Replace library search with explicit version check
- sd_notify() watchdog call was unsetting NOTIFY_SOCKET from env;
this means only first "watchdog ping" was delivered, each
subsequent one did not have socket to be sent to and systemd
was killing service
- after those fixes, enable Watchdog in systemd unit with one
minute intervals
If running under systemd, send back information when reloading
configuration and gracefully shutting down. This gives administator
more information about current Tor daemon state.
If running under systemd, notify the supervisor about current PID
of Tor daemon. This makes systemd unit simpler and more robust:
it will do the right thing regardless of RunAsDaemon settings.
Check for a missing option value in parse_virtual_addr_network
before asserting on the NULL in tor_addr_parse_mask_ports.
This avoids crashing on torrc lines like Vi[rtualAddrNetworkIPv[4|6]]
when no value follows the option.
Bugfix on 0.2.3 (de4cc126cb on 24 November 2012), fixes#14142.
Drop the MIN_REND_INITIAL_POST_DELAY on a testing network to 5 seconds,
but keep the default at 30 seconds.
Reduces the hidden service bootstrap to 25 seconds from around 45 seconds.
Change the default src/test/test-network.sh delay to 25 seconds.
Closes ticket 13401.
TestingDirAuthVoteHSDir ensures that authorities vote the HSDir flag
for the listed relays regardless of uptime or ORPort connectivity.
Respects the value of VoteOnHidServDirectoriesV2.
Partial fix for bug 14067.
Fixes bug 11454, where we would keep around a superseded descriptor
if the descriptor replacing it wasn't at least a week later. Bugfix
on 0.2.1.8-alpha.
Fixes bug 11457, where a certificate with a publication time in the
future could make us discard existing (and subsequent!) certificates
with correct publication times. Bugfix on 0.2.0.3-alpha.
When I made time parsing more strict, I broke the
EntryGuardDownSince line, which relied on two concatenated ISO times
being parsed as a single time.
Fixes bug 14136. Bugfix on 7984fc1531. Bug not in any released
version of Tor.
Also, avoid crashing when we attempt to double-remove an edge
connection from the DNS resolver: just log a bug warning instead.
Fixes bug 14129. Bugfix on 0d20fee2fb, which was in 0.0.7rc1.
jowr found the bug. cypherpunks wrote the fix. I added the log
message and removed the assert.
"Maybe this time should be reduced, since we are considering
guard-related changes as quite important? It would be a pity to
settle on a guard node, then close the Tor client fast and lose that
information."
Closes 12485.
If we decide not to use a new guard because we want to retry older
guards, only close the locally-originating circuits passing through
that guard. Previously we would close all the circuits.
Fixes bug 9819; bugfix on 0.2.1.1-alpha. Reported by "skruffy".
Have clients and authorities both have new behavior, since the
fix for bug 11243 has gone in. But make clients still accept
accept old bogus HSDir descriptors, to avoid fingerprinting trickery.
Fixes bug 9286.
If we're not a relay, we ignore it.
If it's set to 1, we obey ExitPolicy.
If it's set to 0, we force ExitPolicy to 'reject *:*'
And if it's set to auto, then we warn the user if they're running an
exit, and tell them how they can stop running an exit if they didn't
mean to do that.
Fixes ticket 10067
We had a check to block these, but the patch we merged as a1c1fc72
broke this check by making them absolute on demand every time we
opened them. That's not so great though. Instead, we should make them
absolute on startup, and not let them change after that.
Fixes bug 13397; bugfix on 0.2.3.11-alpha.
This happened because we changed AutomapHostsSuffixes to replace "."
with "", since a suffix of "" means "match everything." But our
option handling code for CSV options likes to remove empty entries
when it re-parses stuff.
Instead, let "." remain ".", and treat it specially when we're
checking for a match.
Fixes bug 12509; bugfix on 0.2.0.1-alpha.
This allows hidden services to disable the anti-scanning feature
introduced in 0.2.6.2-alpha. With this option not set, a connection
to an unlisted port closes the circuit. With this option set, only
a RELAY_DONE cell is sent.
Closes ticket #14084.
Supposedly there are a decent number of applications that "support"
IPv6 and SOCKS5 using the FQDN address type. While said applications
should be using the IPv6 address type, allow the connection if
SafeSocks is not set.
Bug not in any released version.
Stop assuming that private addresses are local when checking
reachability in a TestingTorNetwork. Instead, when testing, assume
all OR connections are remote. (This is necessary due to many test
scenarios running all nodes on localhost.)
This assists in bootstrapping a testing Tor network.
Fixes bugs 13718 & 13924.
If the consensus does not contain Exits, Tor will only build internal
circuits. In this case, relevant statuses will contain the word "internal"
as indicated in the Tor control-spec.txt. When bootstrap completes,
Tor will be ready to handle an application requesting an internal
circuit to hidden services at ".onion" addresses.
If a future consensus contains Exits, exit circuits may become available.
Tor already notifies the user at "notice" level if they have no exits in
the consensus, and can therefor only build internal paths.
Consequential change from #13718.
Tor can now build circuits from a consensus with no exits.
But if it tries to build exit circuits, they fail and flood the logs.
The circuit types in the Exit Circuits list below will only be
built if the current consensus has exits. If it doesn't,
only the Internal Circuits will be built. (This can change
with each new consensus.)
Fixes bug #13814, causes fewer path failures due to #13817.
Exit Circuits:
Predicted Exit Circuits
User Traffic Circuits
Most AP Streams
Circuits Marked Exit
Build Timeout Circuits (with exits)
Internal Circuits:
Hidden Service Server Circuits
Hidden Service Client Circuits
Hidden Service AP Streams
Hidden Service Intro Point Streams
Circuits Marked Internal
Build Timeout Circuits (with no exits)
Other Circuits?
If the consensus has no exits (typical of a bootstrapping
test network), allow tor to build circuits once enough
descriptors have been downloaded.
When there are no exits, we always have "enough"
exit descriptors. (We treat the proportion of available
exit descriptors as 100%.)
This assists in bootstrapping a testing Tor network.
Fixes bug 13718.
Makes bug 13161's TestingDirAuthVoteExit non-essential.
(But still useful for speeding up a bootstrap.)
Add router_have_consensus_path() which reports whether
the consensus has exit paths, internal paths, or whether it
just doesn't know.
Used by #13718 and #13814.
count_usable_descriptors now uses named exit_only values:
USABLE_DESCRIPTOR_ALL
USABLE_DESCRIPTOR_EXIT_ONLY
Add debug logging code for descriptor counts.
This (hopefully) resolves nickm's request in bug 13718 to improve
argument readability in nodelist.c.
choose_good_entry_server() now excludes current entry
guards and their families, unless we're in a test network,
and excluding guards would exclude all nodes.
This typically occurs in incredibly small tor networks,
and those using TestingAuthVoteGuard *
This is an incomplete fix, but is no worse than the previous
behaviour, and only applies to minimal, testing tor networks
(so it's no less secure).
Discovered as part of #13718.
Make hidden service port scanning harder by sending back REASON_DONE which
does not disclose that it was in fact an exit policy issue. After that, kill
the circuit immediately to avoid more bad requests on it.
This means that everytime an hidden service exit policy does match, the user
(malicious or not) needs to build a new circuit.
Fixes#13667.
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
When V3AuthVotingInterval is low, decrease the delay on the
If-Modified-Since header passed to directory servers.
This allows us to obtain consensuses promptly when the consensus
interval is very short.
This assists in bootstrapping a testing Tor network.
Fixes bugs 13718 & 13963.
Decrease minimum consensus interval to 10 seconds
when TestingTorNetwork is set. (Or 5 seconds for
the first consensus.)
Fix code that assumes larger interval values.
This assists in quickly bootstrapping a testing
Tor network.
Fixes bugs 13718 & 13823.
Stop requiring exits to have non-zero bandwithcapacity in a
TestingTorNetwork. Instead, when TestingMinExitFlagThreshold is 0,
ignore exit bandwidthcapacity.
This assists in bootstrapping a testing Tor network.
Fixes bugs 13718 & 13839.
Makes bug 13161's TestingDirAuthVoteExit non-essential.
Matthew's autoaddr code returned an undecorated address when trying to check
that the code didn't insert an undecorated one into the map.
This patch fixes this by actually storing the undecorated address in tmp
instead of buf as it was originally intended.
This patch is released under the same license as the original file as
long as the author iscredited.
Signed-off-by: Francisco Blas Izquierdo Riera (klondike) <klondike@gentoo.org>
Document why we divide it by two.
Check for > 0 instead of nonzero for success, since that's what the
manpage says.
Allow watchdog timers greater than 1 second.
It work by notifying systemd on a regular basis. If
there is no notification, the daemon is restarted.
This requires a version newer than the 209 version
of systemd, as it is not supported before.
The original call to getsockopt to know the original address on transparently
proxyed sockets using REDIRECT in iptables failed with IPv6 addresses because
it assumed all sockets used IPv4.
This patch fixes this by using the appropriate options and adding the headers
containing the needed definitions for these.
This patch is released under the same license as the original file as
long as the author iscredited.
Signed-off-by: Francisco Blas Izquierdo Riera (klondike) <klondike@gentoo.org>
The address of an array in the middle of a structure will
always be non-NULL. clang recognises this and complains.
Disable the tautologous and redundant check to silence
this warning.
Fixes bug 14001.
The address of an array in the middle of a structure will
always be non-NULL. clang recognises this and complains.
Disable the tautologous and redundant check to silence
this warning.
A comment about an IPv6 address string incorrectly refers
to an IPv4 address format.
A log buffer is sized 10024 rather than 10240.
Fixes bug 14001.
The two statistics are:
1. number of RELAY cells observed on successfully established
rendezvous circuits; and
2. number of .onion addresses observed as hidden-service
directory.
Both statistics are accumulated over 24 hours, obfuscated by rounding
up to the next multiple of a given number and adding random noise,
and written to local file stats/hidserv-stats.
Notably, no statistics will be gathered on clients or services, but
only on relays.
In circuit_get_open_circ_or_launch(), for a rendezvous circuit,
rend_client_rendcirc_has_opened() but circuit_has_opened() is preferred here
since it will call the right function for a specific circuit purpose.
Furthermore, a controller event is triggered where the former did not.
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
1) Set them to the values that (according to Rob) avoided performance
regressions. This means that the scheduler won't get much exercise
until we implement KIST or something like it.
2) Rename the options to end with a __, since I think they might be
going away, and nobody should mess with them.
3) Use the correct types for the option variables. MEMUNIT needs to be a
uint64_t; UINT needs to be (I know, I know!) an int.
4) Validate the values in options_validate(); do the switch in
options_act(). This way, setting the option to an invalid value on
a running Tor will get backed out.
We add a compression level argument to tor_zlib_new, and use it to
determine how much memory to allocate for the zlib object. We use the
existing level by default, but shift to smaller levels for small
requests when we have been over 3/4 of our memory usage in the past
half-hour.
Closes ticket 11791.
When closing parallel introduction points, the given reason (timeout)
was actually changed to "no reason" thus when the circuit purpose was
CIRCUIT_PURPOSE_C_INTRODUCE_ACK_WAIT, we were reporting an introduction
point failure and flagging it "unreachable". After three times, that
intro point gets removed from the rend cache object.
In the case of CIRCUIT_PURPOSE_C_INTRODUCING, the intro point was
flagged has "timed out" and thus not used until the connection to the HS
is closed where that flag gets reset.
This commit adds an internal circuit reason called
END_CIRC_REASON_IP_NOW_REDUNDANT which tells the closing circuit
mechanism to not report any intro point failure.
This has been observed while opening hundreds of connections to an HS on
different circuit for each connection. This fix makes this use case to
work like a charm.
Fixes#13698.
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
Instead, generate new keys, and overwrite the empty key files.
Adds FN_EMPTY to file_status_t and file_status.
Fixes bug 13111.
Related changes due to review of FN_FILE usage:
Stop generating a fresh .old RSA key file when the .old file is missing.
Avoid overwriting .old key files with empty key files.
Skip loading zero-length extra info store, router store, stats, state,
and key files.
We were only using it when smartlist_choose_node_by_bandwidth_weights
failed. But that function could only fail in the presence of
buggy/ancient authorities or in the absence of a consensus. Either
way, it's better to use sensible defaults and a nicer algorithm.
Now, if a router ever changes its microdescriptor, but the new
microdescriptor SHA256 hash has the same 160-bit prefix as the old
one, we treat it as a new microdescriptor when deciding whether to
copy status information.
(This function also is used to compare SHA1 digests of router
descriptors, but don't worry: the descriptor_digest field either holds
a SHA256 hash, or a SHA1 hash padded with 0 bytes.)
Silence clang warnings under --enable-expensive-hardening, including:
+ implicit truncation of 64 bit values to 32 bit;
+ const char assignment to self;
+ tautological compare; and
+ additional parentheses around equality tests. (gcc uses these to
silence assignment, so clang warns when they're present in an
equality test. But we need to use extra parentheses in macros to
isolate them from other code).
By now, support in the network is widespread and it's time to require
more modern crypto on all Tor instances, whether they're clients or
servers. By doing this early in 0.2.6, we can be sure that at some point
all clients will have reasonable support.
Ensure we securely wipe keys from memory after
crypto_digest_get_digest and init_curve25519_keypair_from_file
have finished using them.
Fixes bug 13477.
Also, refactor the way we handle failed handshakes so that this
warning doesn't propagate itself to "onion_skin_client_handshake
failed" and "circuit_finish_handshake failed" and
"connection_edge_process_relay_cell (at origin) failed."
Resolves warning from 9635.
1. The test that adds things to the cache needs to set the clock back so
that the descriptors it adds are valid.
2. We split ROUTER_NOT_NEW into ROUTER_TOO_OLD, so that we can
distinguish "already had it" from "rejected because of old published
date".
3. We make extrainfo_insert() return a was_router_added_t, and we
make its caller use it correctly. This is probably redundant with
the extrainfo_is_bogus flag.
One pain point in evolving the Tor design and implementing has been
adding code that makes clients reject directory documents that they
previously would have accepted, if those descriptors actually exist.
When this happened, the clients would get the document, reject it,
and then decide to try downloading it again, ad infinitum. This
problem becomes particularly obnoxious with authorities, since if
some authorities accept a descriptor that others don't, the ones
that don't accept it would go crazy trying to re-fetch it over and
over. (See for example ticket #9286.)
This patch tries to solve this problem by tracking, if a descriptor
isn't parseable, what its digest was, and whether it is invalid
because of some flaw that applies to the portion containing the
digest. (This excludes RSA signature problems: RSA signatures
aren't included in the digest. This means that a directory
authority can still put another directory authority into a loop by
mentioning a descriptor, and then serving that descriptor with an
invalid RSA signatures. But that would also make the misbehaving
directory authority get DoSed by the server it's attacking, so it's
not much of an issue.)
We already have a mechanism to mark something undownloadable with
downloadstatus_mark_impossible(); we use that here for
microdescriptors, extrainfos, and router descriptors.
Unit tests to follow in another patch.
Closes ticket #11243.
Bitwise check for the BRIDGE_DIRINFO flag, rather than checking for
equality.
Fixes a (potential) bug where directories offering BRIDGE_DIRINFO,
and some other flag (i.e. microdescriptors or extrainfo),
would be ignored when looking for bridge directories.
Final fix in series for bug 13163.
Document usage of the NO_DIRINFO and ALL_DIRINFO flags clearly in functions
which take them as arguments. Replace 0 with NO_DIRINFO in a function call
for clarity.
Seeks to prevent future issues like 13163.
Stop using the default authorities in networks which provide both
AlternateDirAuthority and AlternateBridgeAuthority.
This bug occurred due to an ambiguity around the use of NO_DIRINFO.
(Does it mean "any" or "none"?)
Partially fixes bug 13163.
Cases that now send errors:
* Malformed IP address (SOCKS5_GENERAL_ERROR)
* CONNECT/RESOLVE request with IP, when SafeSocks is set
(SOCKS5_NOT_ALLOWED)
* RESOLVE_PTR request with FQDN (SOCKS5_ADDRESS_TYPE_NOT_SUPPORTED)
* Malformed FQDN (SOCKS5_GENERAL_ERROR)
* Unknown address type (SOCKS5_ADDRESS_TYPE_NOT_SUPPORTED)
Fixes bug 13314.
Add the TestingDirAuthVoteExit option, a list of nodes to vote Exit for,
regardless of their uptime, bandwidth, or exit policy.
TestingTorNetwork must be set for this option to have any effect.
Works around an issue where authorities would take up to 35 minutes to
give nodes the Exit flag in a test network, despite short consensus
intervals. Partially implements ticket 13161.
Otherwise, when we authority try to do a self-test because of
init-keys, if that self-test can't be launched for whatever reason and
so we close the channel immediately, we crash.
Yes, this a silly way for initialization to work.
In circuit_build_times_calculate_timeout() in circuitstats.c, avoid dividing
by zero in the pareto calculations.
If either the alpha or p parameters are 0, we would divide by zero, yielding
an infinite result; which would be clamped to INT32_MAX anyway. So rather
than dividing by zero, we just skip the offending calculation(s), and
use INT32_MAX for the result.
Division by zero traps under clang -fsanitize=undefined-trap -fsanitize-undefined-trap-on-error.
Avoid 4 null pointer errors under clang shallow analysis (the default when
building under Xcode) by using tor_assert() to prove that the pointers
aren't null. Resolves issue 13284 via minor code refactoring.
Bugfix on ed8f020e205267e6270494634346ab68d830e1d8; bug not in any
released version of Tor. Found by Coverity; this is CID 1239290.
[Yes, I used this commit message before, in 58e813d0fc.
Turns out, that fix wasn't right, since I didn't look up a
screen. :P ]
Uses libscrypt when found; otherwise, we don't have scrypt and we
only support openpgp rfc2440 s2k hashing, or pbkdf2.
Includes documentation and unit tests; coverage around 95%. Remaining
uncovered code is sanity-checks that shouldn't be reachable fwict.
When DisableNetwork is set, do not launch pluggable transport plugins,
and if any are running already, terminate the existing instances.
Resolves ticket 13213.
Allow clients to use optimistic data when connecting to a hidden service,
which should cut out the initial round-trip for client-side programs
including Tor Browser.
(Now that Tor 0.2.2.x is obsolete, all hidden services should support
server-side optimistic data.)
See proposal 181 for details. Implements ticket 13211.
Clients are now willing to send optimistic circuit data (before they
receive a 'connected' cell) to relays of any version. We used to
only do it for relays running 0.2.3.1-alpha or later, but now all
relays are new enough.
Resolves ticket 13153.
Return an error when the second or later arguments of the
"setevents" controller command are invalid events. Previously we
would return success while silently skipping invalid events.
Fixes bug 13205; bugfix on 0.2.3.2-alpha. Reported by "fpxnns".
Stop modifying the value of our DirReqStatistics torrc option just
because we're not a bridge or relay. This bug was causing Tor
Browser users to write "DirReqStatistics 0" in their torrc files
as if they had chosen to change the config.
Fixes bug 4244; bugfix on 0.2.3.1-alpha.
Clients now send the correct address for their chosen rendezvous point
when trying to access a hidden service. They used to send the wrong
address, which would still work some of the time because they also
sent the identity digest of the rendezvous point, and if the hidden
service happened to try connecting to the rendezvous point from a relay
that already had a connection open to it, the relay would reuse that
connection. Now connections to hidden services should be more robust
and faster. Also, this bug meant that clients were leaking to the hidden
service whether they were on a little-endian (common) or big-endian (rare)
system, which for some users might have reduced their anonymity.
Fixes bug 13151; bugfix on 0.2.1.5-alpha.
"At this point in the code, msg has been set to a string
constant. But the tor code checks that msg is not NULL, and the
redundant NULL check confuses the analyser[...] To avoid this
spurious warning, the patch initialises msg to NULL."
Patch from teor. another part of 13157.
Tor Browser includes several ClientTransportPlugin lines in its
torrc-defaults file, leading every Tor Browser user who looks at her
logs to see these notices and wonder if they're dangerous.
Resolves bug 13124; bugfix on 0.2.5.3-alpha.
Technically, we're not allowed to take the address of a member can't
exist relative to the null pointer. That makes me wonder how any sane
compliant system implements the offsetof macro, but let's let sleeping
balrogs lie.
Fixes 13096; patch on 0.1.1.9-alpha; patch from "teor", who was using
clang -fsanitize=undefined-trap -fsanitize-undefined-trap-on-error -ftrapv
(And replay them once we know our first real logs.)
This is an implementation for issue 6938. It solves the problem of
early log mesages not getting sent to log files, but not the issue of
early log messages not getting sent to controllers.
This implements the meat of #12899. This commit should simply remove the
parts of Tor dirauths used to check whether a relay was supposed to be
named or not, it doesn't yet convert to a new mechanism for
reject/invalid/baddir/badexiting relays.
Back in 078d6bcd, we added an event number 0x20, but we didn't make
the event_mask field big enough to compensate.
Patch by "teor". Fixes 13085; bugfix on 0.2.5.1-alpha.
This function never returns non-null, but its usage doesn't reflect
that. Let's make it explicit. This will be mostly overridden by later
commits, so no changes file here.
This is in preparation for a big patch series removing the entire Naming
system from Tor. In its wake, the approved-routers file is being
deprecated, and a replacement option to allow only pre-approved routers
is not being implemented.
This implements a feature from bug 13000. Instead of starting a bwauth
run with this wrong idea about their bw, relays should do the self-test
and then get measured.
When a tor relay starts up and has no historical information about its
bandwidth capability, it uploads a descriptor with a bw estimate of 0.
It then starts its bw selftest, but has to wait 20 minutes to upload the
next descriptor due to the MAX_BANDWIDTH_CHANGE_FREQ delay. This change
should mean that on average, relays start seeing meaningful traffic a
little quicker, since they will have a higher chance to appear in the
consensus with a nonzero bw.
Patch by Roger, changes file and comment by Sebastian.
We're calling mallocfn() and reallocfn() in the HT_GENERATE macro
with the result of a product. But that makes any sane analyzer
worry about overflow.
This patch keeps HT_GENERATE having its old semantics, since we
aren't the only project using ht.h. Instead, define a HT_GENERATE2
that takes a reallocarrayfn.
Most of these are in somewhat non-obvious code where it is probably
a good idea to initialize variables and add extra assertions anyway.
Closes 13036. Patches from "teor".
It's now a protocol-warn, since there's nothing relay operators can
do about a client that sends them a malformed create cell.
Resolves bug 12996; bugfix on 0.0.6rc1.
Previously, we had done this only in the connection_free() case, but
when we called connection_free_() directly from
connections_free_all(), we didn't free the connections.
The fix for bug 4647 accidentally removed our hack from bug 586 that
rewrote HashedControlPassword to __HashedControlSessionPassword when
it appears on the commandline (which allowed the user to set her own
HashedControlPassword in the torrc file while the controller generates
a fresh session password for each run).
Fixes bug 12948; bugfix on 0.2.5.1-alpha.
This modifies the format of the bridge networkstatus documents produced
by the BridgeAuth. The new format adds a `published` line to the header
of the file, before the `flag-thresholds` line. This is done once per
networkstatus file that is written. The timestamp in the `published`
line is the standard ISO 8601 format (with a space as the separator)
used throughout the rest of tor.
* FIXES#12951https://bugs.torproject.org/12951
Using the *_array() functions here confused coverity, and was actually
a bit longer than we needed. Now we just use macros for the repeated
bits, so that we can mention a file and a suffix-appended version in
one line.
We had some code to fix up the 'status' return value to -1 on error
if it wasn't set, but it was unreachable because our code was
correct. Tweak this by initializing status to -1, and then only
setting it to 0 on success. Also add a goto which was missing: its
absence was harmless.
[CID 718614, 718616]
(We allowed it previously, but produced an LD_BUG message when it
happened, which is not consistent
Also, remove inconsistent NULL checks before calling
rend_service_intro_free.
(Removing the check is for CID 718613)
Coverity doesn't like doing NULL checks on things that can't be
NULL; I like checking things where the logic for their not being
NULL is nontrivial. Let's compromise, and make it obvious that this
field can't be NULL.
[Coverity CID 202004]
Coverity thinks that when we do "double x = int1/int2;", we probably
meant "double x = ((double)int1) / int2;". In these cases, we
didn't.
[Coverity CID 1232089 and 1232090]
Two bugs here:
1) We didn't add EXTEND2/EXTENDED2 to relay_command_to_string().
2) relay_command_to_string() didn't log the value of unrecognized
commands.
Both fixed here.
This will fix the warning
"/src/or/config.c:6854:48: error: unused parameter 'group_readable'"
that I introduced while fixing 12864.
Bug not in any released version of Tor.
Implements proposal 215; closes ticket 10163.
Why? From proposal 215:
Consensus method 1 is no longer viable for the Tor network. It
doesn't result in a microdescriptor consensus, and omits other
fields that clients need in order to work well. Consensus methods
under 12 have security issues, since they let a single authority
set a consensus parameter.
...
For example, while Tor 0.2.4.x is under development, authorities
should really not be running anything before Tor 0.2.3.x. Tor
0.2.3.x has supported consensus method 13 since 0.2.3.21-rc, so
it's okay for 0.2.4.x to require 13 as the minimum method. We even
might go back to method 12, since the worst outcome of not using 13
would be some warnings in client logs. Consensus method 12 was a
security improvement, so we don't want to roll back before that.
When we merged the cookieauthfile creation logic in 33c3e60a37, we
accidentally took out this feature. Fixes bug 12864, bugfix on
0.2.5.1-alpha.
Also adds an ExtORPortCookieAuthFileGroupReadable, since there's no
reason not to.
I looked for other places where we set circ->n_chan early, and found
one in circuit_handle_first_hop() right before it calls
circuit_send_next_onion_skin(). If onion_skin_create() fails there,
then n_chan will still be set when circuit_send_next_onion_skin()
returns. We should probably fix that too.
When Tor starts with DisabledNetwork set, it would correctly
conclude that it shouldn't try making circuits, but it would
mistakenly cache this conclusion and continue believing it even
when DisableNetwork is set to 0. Fixes the bug introduced by the
fix for bug 11200; bugfix on 0.2.5.4-alpha.
Those used to be normal to receive on hidden service circuits due to bug
1038, but the buggy Tor versions are long gone from the network so we
can afford to resume watching for them. Resolves the rest of bug 1038;
bugfix on 0.2.1.19.
Roger spotted this on tor-dev in his comments on proposal 221.
(Actually, detect DESTROY vs everything else, since arma likes
network timeout indicating failure but not overload indicating failure.)
Authorities now assign the Guard flag to the fastest 25% of the
network (it used to be the fastest 50%). Also raise the consensus
weight that guarantees the Guard flag from 250 to 2000. For the
current network, this results in about 1100 guards, down from 2500.
This step paves the way for moving the number of entry guards
down to 1 (proposal 236) while still providing reasonable expected
performance for most users.
Implements ticket 12690.
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.)
A new set of unit test cases are provided, as well as introducing
an alternative paradigm and macros to support it. Primarily, each test
case is given its own namespace, in order to isolate tests from each
other. We do this by in the usual fashion, by appending module and
submodule names to our symbols. New macros assist by reducing friction
for this and other tasks, like overriding a function in the global
namespace with one in the current namespace, or declaring integer
variables to assist tracking how many times a mock has been called.
A set of tests for a small-scale module has been included in this
commit, in order to highlight how the paradigm can be used. This
suite gives 100% coverage to status.c in test execution.
My first implementation was broken, since it returned "whether there
is one bridge" rather than "how many bridges."
Also, the implementation for the n_options_out feature in
choose_random_entry_impl was completely broken due to a missing *.
When we successfully create a usable circuit after it previously
timed out for a certain amount of time, we should make sure that
our public IP address hasn't changed and update our descriptor.
In C, it's a bad idea to do this:
char *cp = array;
char *end = array + array_len;
/* .... */
if (cp + 3 >= end) { /* out of bounds */ }
because cp+3 might be more than one off the end of the array, and
you are only allowed to construct pointers to the array elements,
and to an element one past the end. Instead you have to say
if (cp - array + 3 >= array_len) { /* ... */ }
or something like that.
This patch fixes two of these: one in process_versions_cell
introduced in 0.2.0.10-alpha, and one in process_certs_cell
introduced in 0.2.3.6-alpha. These are both tracked under bug
10363. "bobnomnom" found and reported both. See also 10313.
In our code, this is likely to be a problem as we used it only if we
get a nasty allocator that makes allocations end close to (void*)-1.
But it's best not to have to worry about such things at all, so
let's just fix all of these we can find.
According to reports, most programs degrade somewhat gracefully on
getting no answer for an MX or a CERT for www.example.com, but many
flip out completely on a NOTIMPL error.
Also, treat a QTYPE_ALL query as just asking for an A record.
The real fix here is to implement proposal 219 or something like it.
Fixes bug 10268; bugfix on 0.2.0.1-alpha.
Based on a patch from "epoch".
Found by testing with chutney. The old behavior was "fail an
assertion", which obviously isn't optimal.
Bugfix on 8b9a2cb68b290e550695124d7ef0511225b451d5; bug not in any
released version.
Also, stop accepting the old kind of RESOLVED cells with no TTL
fields; they haven't been sent since 0.1.1.6-alpha.
This patch won't work without the fix to #10468 -- it will break
DNSPorts unless they set the proper ipv4/6 flags on entry_connection_t.
Otherwise, it could mung the thing that came over the net on windows,
which would defeat the purpose of recording the unparseable thing.
Fixes bug 11342; bugfix on 0.2.2.1-alpha.
This is a fix for 9963. I say this is a feature, but if it's a
bugfix, it's a bugfix on 0.2.4.18-rc.
Old behavior:
Mar 27 11:02:19.000 [notice] Bootstrapped 50%: Loading relay descriptors.
Mar 27 11:02:20.000 [notice] Bootstrapped 51%: Loading relay descriptors.
Mar 27 11:02:20.000 [notice] Bootstrapped 52%: Loading relay descriptors.
... [Many lines omitted] ...
Mar 27 11:02:29.000 [notice] Bootstrapped 78%: Loading relay descriptors.
Mar 27 11:02:33.000 [notice] We now have enough directory information to build circuits.
New behavior:
Mar 27 11:16:17.000 [notice] Bootstrapped 50%: Loading relay descriptors
Mar 27 11:16:19.000 [notice] Bootstrapped 55%: Loading relay descriptors
Mar 27 11:16:21.000 [notice] Bootstrapped 60%: Loading relay descriptors
Mar 27 11:16:21.000 [notice] Bootstrapped 65%: Loading relay descriptors
Mar 27 11:16:21.000 [notice] Bootstrapped 70%: Loading relay descriptors
Mar 27 11:16:21.000 [notice] Bootstrapped 75%: Loading relay descriptors
Mar 27 11:16:21.000 [notice] We now have enough directory information to build circuits.
Most of these are simple. The only nontrivial part is that our
pattern for using ENUM_BF was confusing doxygen by making declarations
that didn't look like declarations.
In circuitlist_free_all, we free all the circuits, removing them from
the map as we go, but we weren't actually freeing the placeholder
entries that we use to indicate pending DESTROY cells.
Fix for bug 11278; bugfix on the 7912 code that was merged in
0.2.5.1-alpha
There are still quite a few 0.2.3.2x relays running for x<5, and while I
agree they should upgrade, I don't think cutting them out of the network
is a net win on either side.
This contains the obvious implementation using the circuitmux data
structure. It also runs the old (slow) algorithm and compares
the results of the two to make sure that they're the same.
Needs review and testing.
This change prevents LD_BUG warnings and bootstrap failure messages
when we try to do directory fetches when starting with
DisableNetwork == 1, a consensus present, but no descriptors (or
insufficient descriptors) yet.
Fixes bug 11200 and bug 10405. It's a bugfix on 0.2.3.9-alpha.
Thanks to mcs for walking me through the repro instructions!
This is meant to be a better bug 9229 fix -- or at least, one more
in tune with the intent of the original code, which calls
router_retry_directory_downloads() only on the first bridge descriptor.
This prevents long stalls when we're starting with a state file but
with no bridge descriptors. Fixes bug 9229. I believe this bug has
been present since 0.2.0.3-alpha.
By default, after you've made a connection to port XYZ, we assume
you might still want to have an exit ready to connect to XYZ for one
hour. This patch lets you lower that interval.
Implements ticket 91
This should fixes some "hey, that function could have
__attribute__((noreturn))" warnings introduced by f96400d9.
Bug not in any released version of Tor.
We have ignored any ports listed here since 80365b989 (0.0.7rc1),
but we didn't warn the user that we were ignoring them. This patch
adds a warning if you put explicit ports in any of the options
{Socks,Dir}Policy or AuthDir{Reject,Invalid,BadDir,BadExit}. It
also adjusts the manpage to say that ports are ignored.
Fixes ticket 11108.
In a couple of places, to implement the OOM-circuit-killer defense
against sniper attacks, we have counters to remember the age of
cells or data chunks. These timers were based on wall clock time,
which can move backwards, thus giving roll-over results for our age
calculation. This commit creates a low-budget monotonic time, based
on ratcheting gettimeofday(), so that even in the event of a time
rollback, we don't do anything _really_ stupid.
A future version of Tor should update this function to do something
even less stupid here, like employ clock_gettime() or its kin.
Back in 5e762e6a5c, non-exit servers
stopped launching DNS requests for users. So there's no need for them
to see if their DNS answers are hijacked.
Patch from Matt Pagan. I think this is a 965 fix.
For a client using a SocksPort connection and IPv6, the connect reply
from tor daemon did not handle AF_INET6 thus sending back the wrong
payload to the client.
A changes file is provided and this fixes#10987
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
When we have more than two return values, we should really be using
an enum rather than "-2 means this, -1 means that, 0 means this, and
1 or more means a number."
On busy servers, this function takes up something like 3-7% in
different profiles, and gets invoked every time we need to participate
as the midpoint in a hidden service.
So maybe walking through a linked list of all the circuits here wasn't
a good idea.
We log only one message, containing a complete list of what's
wrong. We log the complete list whenever any of the possible things
that could have gotten wrong gets worse.
Fix for #9870. Bugfix on 10480dff01, which we merged in
0.2.5.1-alpha.
This patch splits out some of the functions in OOM handling so that
it's easier to check them without involving the rest of Tor or
requiring that the circuits be "wired up".
It's increasingly apparent that we want to make sure we initialize our
PRNG nice and early, or else OpenSSL will do it for us. (OpenSSL
doesn't do _too_ bad a job, but it's nice to do it ourselves.)
We'll also need this for making sure we initialize the siphash key
before we do any hashes.
I've made an exception for cases where I'm sure that users can't
influence the inputs. This is likely to cause a slowdown somewhere,
but it's safer to siphash everything and *then* look for cases to
optimize.
This patch doesn't actually get us any _benefit_ from siphash yet,
since we don't really randomize the key at any point.
These options were added back in 0.1.2.5-alpha, but no longer make any
sense now that all directories support tunneled connections and
BEGIN_DIR cells. These options were on by default; now they are
always-on.
This is a fix for 10849, where TunnelDirConns 0 would break hidden
services -- and that bug arrived, I think, in 0.2.0.10-alpha.
(There is no longer meaningfully any such thing as a HS authority,
since we stopped uploading or downloading v0 hs descriptors in
0.2.2.1-alpha.)
Implements #10881, and part of #10841.
This patch removes an "if (chan)" that occurred at a place where
chan was definitely non-NULL. Having it there made some static
analysis tools conclude that we were up to shenanigans.
This resolves#9979.
Right now this accounts for about 1% of circuits over all, but if you
pick a guard that's running 0.2.3, it will be about 6% of the circuits
running through that guard.
Making sure that every circuit has at least one ntor link means that
we're getting plausibly good forward secrecy on every circuit.
This implements ticket 9777,
It's possible to set your ExitNodes to contains only exits that don't
have the Exit flag. If you do that, we'll decide that 0 of your exits
are working. Instead, in that case we should look at nodes which have
(or which might have) exit policies that don't reject everything.
Fix for bug 10543; bugfix on 0.2.4.10-alpha.
According to control spec, longname should not contain any spaces and is
consists only of identy_digest + nickname
added two functions:
* node_get_verbose_nickname_by_id()
* node_describe_longname_by_id()
If you want a slow shutdown, send SIGNAL SHUTDOWN.
(Why not just have the default be SIGNAL QUIT? Because this case
should only happen when an owning controller has crashed, and a
crashed controller won't be able to give the user any "tor is
shutting down" feedback, and so the user gets confused for a while.
See bug 10449 for more info)
I'm doing this because:
* User doesn't mean you're running as root, and running as root
doesn't mean you've set User.
* It's possible that the user has done some other
capability-based hack to retain the necessary privileges.
The remaining vestige is that we continue to publish the V2dir flag,
and that, for the controller, we continue to emit v2 directory
formats when requested.
Previously, we would sometimes decide in directory_get_from_hs_dir()
to connect to an excluded node, and then later in
directory_initiate_command_routerstatus_rend() notice that it was
excluded and strictnodes was set, and catch it as a stopgap.
Additionally, this patch preferentially tries to fetch from
non-excluded nodes even when StrictNodes is off.
Fix for bug #10722. Bugfix on 0.2.0.10-alpha (the v2 hidserv directory
system was introduced in e136f00ca). Reported by "mr-4".
If we don't, we can wind up with a wedged cpuworker, and write to it
for ages and ages.
Found by skruffy. This was a bug in 2dda97e8fd, a.k.a. svn
revision 402. It's been there since we have been using cpuworkers.
When I introduced the unusable_for_new_circuits flag in
62fb209d83, I had a spurious ! in the
circuit_stream_is_being_handled loop. This made us decide that
non-unusable circuits (that is, usable ones) were the ones to avoid,
and caused it to launch a bunch of extra circuits.
Fixes bug 10456; bugfix on 0.2.4.12-alpha.
When we wrote the directory request statistics code in August 2009, we
thought that these statistics were only relevant for bridges, and that
bridges should not report them. That's why we added a switch to discard
relevant observations made by bridges. This code was first released in
0.2.2.1-alpha.
In May 2012 we learned that we didn't fully disable directory request
statistics on bridges. Bridges did report directory request statistics,
but these statistics contained empty dirreq-v3-ips and dirreq-v3-reqs
lines. But the remaining dirreq-* lines have always been non-empty. (We
didn't notice for almost three years, because directory-request statistics
were disabled by default until 0.2.3.1-alpha, and all statistics have been
removed from bridge descriptors before publishing them on the metrics
website.)
Proposal 201, created in May 2012, suggests to add a new line called
bridge-v3-reqs that is similar to dirreq-v3-reqs, but that is published
only by bridges. This proposal is still open as of December 2013.
Since October 2012 we're using dirreq-v3-resp (not -reqs) lines in
combination with bridge-ips lines to estimate bridge user numbers; see
task 8462. This estimation method has superseded the older approach that
was only based on bridge-ips lines in November 2013. Using dirreq-v3-resp
and bridge-ips lines is a workaround. The cleaner approach would be to
use dirreq-v3-reqs instead.
This commit makes bridges report the same directory request statistics as
relays, including dirreq-v3-ips and dirreq-v3-reqs lines. It makes
proposal 201 obsolete.
In 0.2.3.8-alpha we attempted to "completely disable stats if we aren't
running as a relay", but instead disabled them only if we aren't running
as a server.
This commit leaves DirReqStatistics enabled on both relays and bridges,
and disables (Cell,Entry,ExitPort)Statistics on bridges.
The 'body' field of a microdesc_t holds a strdup()'d value if the
microdesc's saved_location field is SAVED_IN_JOURNAL or
SAVED_NOWHERE, and holds a pointer to the middle of an mmap if the
microdesc is SAVED_IN_CACHE. But we weren't setting that field
until a while after we parsed the microdescriptor, which left an
interval where microdesc_free() would try to free() the middle of
the mmap().
This patch also includes a regression test.
This is a fix for #10409; bugfix on 0.2.2.6-alpha.
The old behavior was that NULL matched only bridges without known
identities; the correct behavior is that NULL should match all
bridges (assuming that their addr:port matches).
We were checking whether a 8-bit length field had overflowed a
503-byte buffer. Unless somebody has found a way to store "504" in a
single byte, it seems unlikely.
Fix for 10313 and 9980. Based on a pach by Jared L Wong. First found
by David Fifield with STACK.
It's conceivable (but probably impossible given our code) that lseek
could return -1 on an error; when that happens, we don't want off to
become -1.
Fixes CID 1035124.
This was a mistake in the merge commit 7a2b30fe16. It
would have made the CellStatistics code give completely bogus
results. Bug not in any released Tor.
We had accidentially grown two fake ones: one for backtrace.c, and one
for sandbox.c. Let's do this properly instead.
Now, when we configure logs, we keep track of fds that should get told
about bad stuff happening from signal handlers. There's another entry
point for these that avoids using non-signal-handler-safe functions.
On platforms with the backtrace/backtrace_symbols_fd interface, Tor
can now dump stack traces on assertion failure. By default, I log
them to DataDir/stack_dump and to stderr.
Conflicts:
src/or/or.h
src/or/relay.c
Conflicts were simple to resolve. More fixes were needed for
compilation, including: reinstating the tv_to_msec function, and renaming
*_conn_cells to *_chan_cells.
In proposal 157, we added a cross-certification element for
directory authority certificates. We implemented it in
0.2.1.9-alpha. All Tor directory authorities now generate it.
Here, as planned, make it required, so that we can finally close
proposal 157.
The biggest change in the code is in the unit test data, where some
old hardcoded certs that we made long ago have become no longer
valid and now need to be replaced.
Previously, when we ran low on memory, we'd close whichever circuits
had the most queued cells. Now, we close those that have the
*oldest* queued cells, on the theory that those are most responsible
for us running low on memory, and that those are the least likely to
actually drain on their own if we wait a little longer.
Based on analysis from a forthcoming paper by Jansen, Tschorsch,
Johnson, and Scheuermann. Fixes bug 9093.
Roger spotted this on tor-dev in his comments on proposal 221.
We etect DESTROY vs everything else, since arma likes network
timeout indicating failure but not overload indicating failure.
Don't cast uint64_t * to const uint64_t * explicitly. The cast is always
safe, so C does it for us. Doing the cast explitictly can hide bugs if
the input is secretly the wrong type.
Suggested by Nick.
As a bridge authority, before we create our networkstatus document, we
should compute the thresholds needed for the various status flags
assigned to each bridge based on the status of all other bridges. We
then add these thresholds to the networkstatus document for easy access.
Fixes for #1117 and #9859.
Also fix a bug where if the guard we choose first doesn't answer, we
would try the second guard, but once we connected to the second guard
we would abandon it and retry the first one, slowing down bootstrapping.
The fix in both cases is to treat all our initially chosen guards as
acceptable to use.
Fixes bug 9946.
We had updated our "do we have enough microdescs to begin building
circuits?" logic most recently in 0.2.4.10-alpha (see bug 5956), but we
left the bootstrap status event logic at "how far through getting 1/4
of them are we?"
Fixes bug 9958; bugfix on 0.2.2.36, which is where they diverged (see
bug 5343).
The old code had logic to use a shorter path length if we didn't
have enough nodes. But we don't support 2-node networks anwyay.
Fix for #9926. I'm not calling this a bugfix on any particular
version, since a 2-node network would fail to work for you for a lot
of other reasons too, and it's not clear to me when that began, or if
2-node networks would ever have worked.
By calling circuit_n_chan_done() unconditionally on close, we were
closing pending connections that might not have been pending quite for
the connection we were closing. Fix for bug 9880.
Thanks to skruffy for finding this and explaining it patiently until
we understood.
this was causing directory authorities to send a time of 0 on all
connections they generated themselves, which means everybody reachability
test caused a time skew warning in the log for that relay.
(i didn't just revert, because the changes file has been modified by
other later commits.)
This isn't actually much of an issue, since only relays send
AUTHENTICATE cells, but while we're removing timestamps, we might as
well do this too.
Part of proposal 222. I didn't take the approach in the proposal of
using a time-based HMAC, since that was a bad-prng-mitigation hack
from SSL3, and in real life, if you don't have a good RNG, you're
hopeless as a Tor server.
For now, round down to the nearest 10 minutes. Later, eliminate entirely by
setting a consensus parameter.
(This rounding is safe because, in 0.2.2, where the timestamp mattered,
REND_REPLAY_TIME_INTERVAL was a nice generous 60 minutes.)
We were freeing these on exit, but when we added the dl_status_map
field to them in fddb814f, we forgot to arrange for it to be freed.
I've moved the cert_list_free() code into its own function, and added
an appropriate dsmap_free() call.
Fixes bug 9644; bugfix on 0.2.4.13-alpha.
The problem was that the server_identity_key_is_set() function could
return true under conditions where we don't really have an identity
key -- specifically, where we used to have one, but we stopped being a
server.
This is a fix for 6979; bugfix on 0.2.2.18-alpha where we added that
assertion to get_server_identity_key().
Whenever we had an non-option commandline arguments *and*
option-bearing commandline arguments on the commandline, we would save
only the latter across invocations of options_init_from_torrc, but
take their existence as license not to re-parse the former. Yuck!
Incidentally, this fix lets us throw away the backup_arg[gv] logic.
Fix for bug 9746; bugfix on d98dfb3746,
not in any released Tor. Found by Damian. Thanks, Damian!
This just goes to show: never cast a function pointer. Found while
testing new command line parse logic.
Bugfix on 1293835440, which implemented
6752: Not in any released tor.
Fall back to SOMAXCONN if INT_MAX doesn't work.
We'd like to do this because the actual maximum is overrideable by the
kernel, and the value in the header file might not be right at all.
All implementations I can find out about claim that this is supported.
Fix for 9716; bugfix on every Tor.
Now we explicitly check for overflow.
This approach seemed smarter than a cascade of "change int to unsigned
int and hope nothing breaks right before the release".
Nick, feel free to fix in a better way, maybe in master.
This would make us do testing circuits "even when cbt is disabled by
consensus, or when we're a directory authority, or when we've failed
to write cbt history to our state file lately." (Roger's words.)
This is a fix for 9671 and an improvement in our fix for 5049.
The original misbehavior was in 0.2.2.14-alpha; the incomplete
fix was in 0.2.3.17-beta.
(In practice they don't exist, but so long as we're making changes for
standards compliance...)
Also add several more unit tests for good and bad URL types.
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.
Now we can compute the hash and signature of a dirobj before
concatenating the smartlist, and we don't need to play silly games
with sigbuf and realloc any more.
I believe this was introduced in 6bc071f765, which makes
this a fix on 0.2.0.10-alpha. But my code archeology has not extended
to actually testing that theory.
We were mixing bandwidth file entries (which are in kilobytes) with
router_get_advertised_bw() entries, which were in bytes.
Also, use router_get_advertised_bandwidth_capped() for credible_bandwidth.
Since 7536c40 only DNS results for real SOCKS requests are added to the cache,
but not DNS results for DNSPort queries or control connection RESOLVE queries.
Only cache additions would trigger ADDRMAP events on successful resolve.
Change it so that DNS results received after a RESOLVE command also generate
ADDRMAP events.
There was a bug in Tor prior to 0.2.4.10-alpha that allowed counts to
become invalid. Clipping the counts at startup allows us to rule out
log messages due to corruption from these prior Tor versions.
This was causing dirauths to emit flag weight validation warns if there
was a sufficiently large amount of badexit bandwidth to make a difference in
flag weight results.
It seems that some versions of clang that would prefer the
-Wswitch-enum compiler flag to warn about switch statements with
missing enum values, even if those switch statements have a
default.
Fixes bug 8598; bugfix on 0.2.4.10-alpha.
Found while investigating 8093, but probably not the cause of it,
since this bug would result in us sending too few SENDMEs, not in us
receiving SENDMEs unexpectedly.
Bugfix on the fix for 7889, which has appeared in 0.2.4.10-alpha, but
not yet in any released 0.2.3.x version.
It can never be NULL, since it's an array in bridge_line_t.
Introduced in 266f8cddd8. Found by coverity; this is CID 992691. Bug
not in any released Tor.
If we get a write error on a SOCKS connection, we can't send a
SOCKS reply, now can we?
This bug has been here since 36baf7219, where we added the "hey, I'm
closing an AP connection but I haven't finished the socks
handshake!" message. It's bug 8427.
Also, don't call the exit node 'reject *' unless our decision to pick
that node was based on a non-summarized version of that node's exit
policy.
rransom and arma came up with the ideas for this fix.
Fix for 7582; the summary-related part is a bugfix on 0.2.3.2-alpha.
When we're hibernating, the main reqason we can't bootstrap will
always be that we're hibernating: reporting anything else at severity
WARN is pointless.
Fixes part of 7302.
This bug affects hosts where time_t is unsigned, which AFAICT does
not include anything we currently support. (It _does_ include
OpenVMS, about a month of BSD4.2's history[1], and a lot of the 1970s.)
There are probably more bugs when time_t is unsigned. This one was
[1] http://mail-index.netbsd.org/tech-userlevel/1998/06/04/0000.html
This time, I'm checking whether our calculated offset matches our
real offset, in each case, as we go along. I don't think this is
the bug, but it can't hurt to check.
This should have been 2 bytes all along, since version numbers can
be 16 bits long. This isn't a live bug, since the call to
is_or_protocol_version_known in channel_tls_process_versions_cell
will reject any version number not in the range 1..4. Still, let's
fix this before we accidentally start supporting version 256.
Reported pseudonymously. Fixes bug 8062; bugfix on 0.2.0.10-alpha --
specifically, on commit 6fcda529, where during development I
increased the width of a version to 16 bits without changing the
type of link_proto.
Our ++ should have been += 2. This means that we'd accept version
numbers even when they started at an odd position.
This bug should be harmless in practice for so long as every version
number we allow begins with a 0 byte, but if we ever have a version
number starting with 1, 2, 3, or 4, there will be trouble here.
Fix for bug 8059, reported pseudonymously. Bugfix on 0.2.0.10-alpha
-- specifically, commit 6fcda529, where during development I
increased the width of a version to 16 bits without changing the
loop step.
I have no idea whether b0rken clients will DoS the network if the v2
authorities all turn this on or not. It's experimental. See #6783 for
a description of how to test it more or less safely, and please be
careful!
Now that circid_t is 4 bytes long, the default integer promotions will
leave it alone when sizeof(int) == 4, which will leave us formatting an
unsigned as an int. That's technically undefined behavior.
Fixes bug 8447 on bfffc1f0fc. Bug not
in any released Tor.
In a number of places, we decrement timestamp_dirty by
MaxCircuitDirtiness in order to mark a stream as "unusable for any
new connections.
This pattern sucks for a few reasons:
* It is nonobvious.
* It is error-prone: decrementing 0 can be a bad choice indeed.
* It really wants to have a function.
It can also introduce bugs if the system time jumps backwards, or if
MaxCircuitDirtiness is increased.
So in this patch, I add an unusable_for_new_conns flag to
origin_circuit_t, make it get checked everywhere it should (I looked
for things that tested timestamp_dirty), and add a new function to
frob it.
For now, the new function does still frob timestamp_dirty (after
checking for underflow and whatnot), in case I missed any cases that
should be checking unusable_for_new_conns.
Fixes bug 6174. We first used this pattern in 516ef41ac1,
which I think was in 0.0.2pre26 (but it could have been 0.0.2pre27).
Without this patch, there's no way to know what went wrong when we
fail to parse a torrc line entirely (that is, we can't turn it into
a K,V pair.) This patch introduces a new function that yields an
error message on failure, so we can at least tell the user what to
look for in their nonfunctional torrc.
(Actually, it's the same function as before with a new name:
parse_config_line_from_str is now a wrapper macro that the unit
tests use.)
Fixes bug 7950; fix on 0.2.0.16-alpha (58de695f90) which first
introduced the possibility of a torrc value not parsing correctly.
This patch moves the measured_bw field and the has_measured_bw field
into vote_routerstatus_t, since only votes have 'Measured=XX' set on
their weight line.
I also added a new bw_is_unmeasured flag to routerstatus_t to
represent the Unmeasured=1 flag on a w line. Previously, I was using
has_measured_bw for this, which was quite incorrect: has_measured_bw
means that the measured_bw field is set, and it's probably a mistake
to have it serve double duty as meaning that 'baandwidth' represents a
measured value.
While making this change,I also found a harmless but stupid bug in
dirserv_read_measured_bandwidths: It assumes that it's getting a
smartlist of routerstatus_t, when really it's getting a smartlist of
vote_routerstatus_t. C's struct layout rules mean that we could never
actually get an error because of that, but it's still quite incorrect.
I fixed that, and in the process needed to add two more sorting and
searching helpers.
Finally, I made the Unmeasured=1 flag get parsed. We don't use it for
anything yet, but someday we might.
This isn't complete yet -- the new 2286 unit test doesn't build.
Instead of capping whenever a router has fewer than 3 measurements,
we cap whenever a router has fewer than 3 measurements *AND* there
are at least 3 authorities publishing measured bandwidths.
We also generate bandwidth lines with a new "Unmeasured=1" flag,
meaning that we didn't have enough observations for a node to use
measured bandwidth values in the authority's input, whether we capped
it or not.
Stop marking every relay as having been down for one hour every
time we restart a directory authority. These artificial downtimes
were messing with our Stable and Guard flag calculations.
Fixes bug 8218 (introduced by the fix for 1035). Bugfix on 0.2.2.23-alpha.
Apparently something in the directory guard code made it possible
for the same node to get added as a guard over and over when there
were no actual running guard nodes.
Relays used to check every 10 to 60 seconds, as an accidental side effect
of calling directory_fetches_from_authorities() when considering doing
a directory fetch. The fix for bug 1992 removes that side effect. At the
same time, bridge relays never had the side effect, leading to confused
bridge operators who tried crazy tricks to get their bridges to notice
IP address changes (see ticket 1913).
The new behavior is to reinstate an every-60-seconds check for both
public relays and bridge relays, now that the side effect is gone.
For example, we were doing a resolve every time we think about doing a
directory fetch. Now we reuse the cached answer in some cases.
Fixes bugs 1992 (bugfix on 0.2.0.20-rc) and 2410 (bugfix on
0.1.2.2-alpha).
When we compute the estimated microseconds we need to handle our
pending onionskins, we could (in principle) overflow a uint32_t if
we ever had 4 million pending onionskins before we had any data
about how onionskins take. Nevertheless, let's compute it properly.
Fixes bug 8210; bugfix on 0.2.4.10. Found by coverity; this is CID
980651.
Coverity is worried that we're checking entry_conn in some cases,
but not in the case where we set entry_conn->pending_optimistic_data.
This commit should calm it down (CID 718623).
The refactoring in commit 471ab34032 wasn't complete enough: we
were checking the auth_len variable, but never actually setting it,
so it would never seem that authentication had been provided.
This commit also removes a bunch of unused variables from
rend_service_introduce, whose unusedness we hadn't noticed because
we were wiping them at the end of the function.
Fix for bug 8207; bugfix on 0.2.4.1-alpha.
It returns the method by which we decided our public IP address
(explicitly configured, resolved from explicit hostname, guessed from
interfaces, learned by gethostname).
Now we can provide more helpful log messages when a relay guesses its IP
address incorrectly (e.g. due to unexpected lines in /etc/hosts). Resolves
ticket 2267.
While we're at it, stop sending a stray "(null)" in some cases for the
server status "EXTERNAL_ADDRESS" controller event. Resolves bug 8200.
since router_parse_entry_from_string() already checks whether
!tor_inet_aton(router->address, &in)
(And no need to print address, since router_describe does that.)
- Document the key=value format.
- Constify equal_sign_pos.
- Pass some strings that are about to be logged to escape().
- Update documentation and fix some bugs in tor_escape_str_for_socks_arg().
- Use string_is_key_value() in parse_bridge_line().
- Parenthesize a forgotten #define
- Add some more comments.
- Add some more unit test cases.
This check isn't necessary (see comment on #7801), but it took at
least two smart people a little while to see why it wasn't necessary,
so let's have it in to make the code more readable.
We need a weak RNG in a couple of places where the strong RNG is
both needless and too slow. We had been using the weak RNG from our
platform's libc implementation, but that was problematic (because
many platforms have exceptionally horrible weak RNGs -- like, ones
that only return values between 0 and SHORT_MAX) and because we were
using it in a way that was wrong for LCG-based weak RNGs. (We were
counting on the low bits of the LCG output to be as random as the
high ones, which isn't true.)
This patch adds a separate type for a weak RNG, adds an LCG
implementation for it, and uses that exclusively where we had been
using the platform weak RNG.
If we're deciding on a node's bandwidth based on "Bandwidth="
declarations, clip it to "20" or to the maxunmeasuredbw parameter,
if it's voted on.
This adds a new consensus method.
This is "part A" of bug 2286
Authorities don't set is_possible_guard on node_t, so they were
never deciding that they could build enough paths. This is a quick
and dirty fix.
Bug not in any released version of Tor
These seem to have gotten conflicted out of existence while mike was
working on path bias stuff.
Thanks to sysrqb for collecting these in a handy patch.
Now we can specify to skip bridges that wouldn't be able to answer the
type of dir fetch we're launching.
It's still the responsibility of the rest of the code to prevent us from
launching a given dir fetch if we have no bridges that could handle it.
Now as we move into a future where most bridges can handle microdescs
we will generally find ourselves using them, rather than holding back
just because one of our bridges doesn't use them.
When we first implemented TLS, we assumed in conneciton_handle_write
that a TOR_TLS_WANT_WRITE from flush_buf_tls meant that nothing had
been written. But when we moved our buffers to a ring buffer
implementation back in 0.1.0.5-rc (!), we broke that invariant: it's
possible that some bytes have been written but nothing.
That's bad. It means that if we do a sequence of TLS writes that ends
with a WANTWRITE, we don't notice that we flushed any bytes, and we
don't (I think) decrement buckets.
Fixes bug 7708; bugfix on 0.1.0.5-rc
Also, deprecate the torrc options for the scaling values. It's unlikely anyone
but developers will ever tweak them, even if we provided a single ratio value.
This is meant to avoid conflict with the built-in log() function in
math.h. It resolves ticket 7599. First reported by dhill.
This was generated with the following perl script:
#!/usr/bin/perl -w -i -p
s/\blog\(LOG_(ERR|WARN|NOTICE|INFO|DEBUG)\s*,\s*/log_\L$1\(/g;
s/\blog\(/tor_log\(/g;
Instead of hardcoding the minimum fraction of possible paths to 0.6, we
take it from the user, and failing that from the consensus, and
failing that we fall back to 0.6.
Previously we did this based on the fraction of descriptors we
had. But really, we should be going based on what fraction of paths
we're able to build based on weighted bandwidth, since otherwise a
directory guard or two could make us behave quite oddly.
Implementation for feature 5956
If any circuits were opened during a scaling event, we were scaling attempts
and successes by different amounts. This leads to rounding error.
The fix is to record how many circuits are in a state that hasn't been fully
counted yet, and subtract that before scaling, and add it back afterwords.
Since they use RELAY_EARLY (which can be seen by all hops on the path),
it's not safe to say they actually count as a successful use.
There are also problems with trying to allow them to finish extending due to
the circuit purpose state machine logic. It is way less complicated (and
possibly more semantically coherent) to simply wait until we actually try to
do something with them before claiming we 'used' them.
Also, we shouldn't call timed out circuits 'used' either, for semantic
consistency.
An adversary could let the first stream request succeed (ie the resolve), but
then tag and timeout the remainder (via cell dropping), forcing them on new
circuits.
Rolling back the state will cause us to probe such circuits, which should lead
to probe failures in the event of such tagging due to either unrecognized
cells coming in while we wait for the probe, or the cipher state getting out
of sync in the case of dropped cells.
Path use bias measures how often we can actually succeed using the circuits we
actually try to use. It is a subset of path bias accounting, but it is
computed as a separate statistic because the rate of client circuit use may
vary depending on use case.
This is a minimal refactoring to expose the weighted bandwidth
calculations for each node so I can use them to see what fraction of
nodes, weighted by bandwidth, we have descriptors for.
This is ticket 7706, reported by "bugcatcher." The rationale here
is that if somebody says 'ExcludeNodes {tv}', then they probably
don't just want to block definitely Tuvaluan nodes: they also want
to block nodes that have unknown country, since for all they know
such nodes are also in Tuvalu.
This behavior is controlled by a new GeoIPExcludeUnknown autobool
option. With the default (auto) setting, we exclude ?? and A1 if
any country is excluded. If the option is 1, we add ?? and A1
unconditionally; if the option is 0, we never add them.
(Right now our geoip file doesn't actually seem to include A1: I'm
including it here in case it comes back.)
This feature only takes effect if you have a GeoIP file. Otherwise
you'd be excluding every node.
The implementation is pretty straightforward: parse_extended_hostname() is
modified to drop any leading components from an address like
'foo.aaaaaaaaaaaaaaaa.onion'.
This is an automatically generated commit, from the following perl script,
run with the options "-w -i -p".
s/smartlist_string_num_isin/smartlist_contains_int_as_string/g;
s/smartlist_string_isin((?:_case)?)/smartlist_contains_string$1/g;
s/smartlist_digest_isin/smartlist_contains_digest/g;
s/smartlist_isin/smartlist_contains/g;
s/digestset_isin/digestset_contains/g;
In 6fbdf635 we added a couple of statements like:
if (test) {
...
};
The extraneous semicolons there get flagged as worrisome empty
statements by the cparser library, so let's fix them.
Patch by Christian Grothoff; fixes bug 7115.
Otherwise, it's possible to create streams or circuits with these
bogus IDs, leading to orphaned circuits or streams, or to ones that
can cause bandwidth DOS problems.
Fixes bug 7889; bugfix on all released Tors.
In general, if we tried to use a circ for a stream, but then decided to place
that stream on a different circuit, we need to probe the original circuit
before deciding it was a "success".
We also need to do the same for cannibalized circuits that go unused.
This makes removing items from the middle of the queue into an O(1)
operation, which could prove important as we let onionqueues grow
longer.
Doing this actually makes the code slightly smaller, too.
The right way to set "MaxOnionsPending" was to adjust it until the
processing delay was appropriate. So instead, let's measure how long
it takes to process onionskins (sampling them once we have a big
number), and then limit the queue based on its expected time to
finish.
This change is extra-necessary for ntor, since there is no longer a
reasonable way to set MaxOnionsPending without knowing what mix of
onionskins you'll get.
This patch also reserves 1/3 of the onionskin spots for ntor
handshakes, on the theory that TAP handshakes shouldn't be allowed to
starve their speedier cousins. We can change this later if need be.
Resolves 7291.
The unit of work sent to a cpuworker is now a create_cell_t; its
response is now a created_cell_t. Several of the things that call or
get called by this chain of logic now take create_cell_t or
created_cell_t too.
Since all cpuworkers are forked or spawned by Tor, they don't need a
stable wire protocol, so we can just send structs. This saves us some
insanity, and helps p
As elsewhere, it makes sense when adding or extending a cell type to
actually make the code to parse it into a separate tested function.
This commit doesn't actually make anything use these new functions;
that's for a later commit.
The handshake_digest field was never meaningfully a digest *of* the
handshake, but rather is a digest *from* the handshake that we exapted
to prevent replays of ESTABLISH_INTRO cells. The ntor handshake will
generate it as more key material rather than taking it from any part
of the circuit handshake reply..
I'm going to want a generic "onionskin" type and set of wrappers, and
for that, it will be helpful to isolate the different circuit creation
handshakes. Now the original handshake is in onion_tap.[ch], the
CREATE_FAST handshake is in onion_fast.[ch], and onion.[ch] now
handles the onion queue.
This commit does nothing but move code and adjust header files.
Here we try to handle curve25519 onion keys from generating them,
loading and storing them, publishing them in our descriptors, putting
them in microdescriptors, and so on.
This commit is untested and probably buggy like whoa
This patch moves curve25519_keypair_t from src/or/onion_ntor.h to
src/common/crypto_curve25519.h, and adds new functions to generate,
load, and store keypairs.
The ntor handshake--described in proposal 216 and in a paper by
Goldberg, Stebila, and Ustaoglu--gets us much better performance than
our current approach.
Our old warn_nonlocal_client_ports() would give a bogus warning for
every nonlocal port every time it parsed any ports at all. So if it
parsed a nonlocal socksport, it would complain that it had a nonlocal
socksport...and then turn around and complain about the nonlocal
socksport again, calling it a nonlocal transport or nonlocal dnsport,
if it had any of those.
Fixes bug 7836; bugfix on 0.2.3.3-alpha.
mr-4 reports on #7799 that he was seeing it several times per second,
which suggests that things had gone very wrong.
This isn't a real fix, but it should make Tor usable till we can
figure out the real issue.
This implements the server-side of proposal 198 by detecting when
clients lack the magic list of ciphersuites that indicates that
they're lying faking some ciphers they don't really have. When
clients lack this list, we can choose any cipher that we'd actually
like. The newly allowed ciphersuites are, currently, "All ECDHE-RSA
ciphers that openssl supports, except for ECDHE-RSA-RC4".
The code to detect the cipher list relies on on (ab)use of
SSL_set_session_secret_cb.
It's important not to call choose_array_element_by_weight and then
pass its return value unchecked to smartlist_get : it is allowed to
return -1.
Fixes bug 7756; bugfix on 4e3d07a6 (not in any released Tor)
This is good enough to give P_success >= 999,999,999/1,000,000,000 so
long as the address space is less than 97.95 full. It'd be ridiculous
for that to happen for IPv6, and usome reasonable assumptions, it
would also be pretty silly for IPv4.
With an IPv6 virtual address map, we can basically hand out a new
IPv6 address for _every_ address we connect to. That'll be cool, and
will let us maybe get around prop205 issues.
This uses some fancy logic to try to make the code paths in the ipv4
and the ipv6 case as close as possible, and moves to randomly
generated addresses so we don't need to maintain those stupid counters
that will collide if Tor restarts but apps don't.
Also has some XXXX items to fix to make this useful. More design
needed.
This function gives us a single place to set reasonable default flags
for port_cfg_t entries, to avoid bugs like the one where we weren't
setting ipv4_traffic_ok to 1 on SocksPorts initialized in an older
way.
(This is part 2 of making DNS cache use enabled/disabled on a
per-client port basis. This implements the CacheIPv[46]DNS options,
but not the UseCachedIPv[46] ones.)
(This is part 1 of making DNS cache use enabled/disabled on a
per-client port basis. These options are shuffled around correctly,
but don't do anything yet.)
We want to be saying fast_mem{cmp,eq,neq} when we're doing a
comparison that's allowed to exit early, or tor_mem{cmp,eq,neq} when
we need a data-invariant timing. Direct use of memcmp tends to imply
that we haven't thought about the issue.
This has several advantages, including more resilience to ambient failure.
I still need to rename all the first_hop vars tho.. Saving that for a separate
commit.
Turns out there's more than one way to block a tagged circuit.
This seems to successfully handle all of the normal exit circuits. Hidden
services need additional tweaks, still.
This replaces the old FallbackConsensus notion, and should provide a
way -- assuming we pick reasonable nodes! -- to give clients
suggestions of placs to go to get their first consensus.
Now creating a dir_server_t and adding it are separate functions, and
there are frontend functions for adding a trusted dirserver and a
fallback dirserver.
We use trusted_dir_server_t for two pieces of functionality: a list of
all directory authorities, and a list of initial places to look for
a directory. With this patch we start to separate those two roles.
There is as of now no actual way to be a fallback directory without being
an authority.
This is a customizable extract-and-expand HMAC-KDF for deriving keys.
It derives from RFC5869, which derives its rationale from Krawczyk,
H., "Cryptographic Extraction and Key Derivation: The HKDF Scheme",
Proceedings of CRYPTO 2010, 2010, <http://eprint.iacr.org/2010/264>.
I'm also renaming the existing KDF, now that Tor has two of them.
This is the key derivation scheme specified in ntor.
There are also unit tests.
This one is necessary for sending BEGIN cells with sane flags when
self-testing a directory port. All real entry connections were
getting their ipv{4,6}_traffic_ok flags set from their listeners, and
for begindir entry connections we didn't care, but for directory
self-testing, we had a problem.
Fixes at least one more case of 7493; if there are more lingering
cases of 7493, this might fix them too.
Bug not in any released version of Tor.
Looks like when i was writing the code to set the ipv4_traffic flag on
port_cfg_t, I missed some cases, such as the one where the port was
set from its default value.
Fix for 7493. Bug not in any released Tor.
Previously, I was freaking out about passing an unspec address to
dns_found_answer() on an error, since I was using the address type to
determine whether the error was an error on an ipv4 address lookup or
on an ipv6 address lookup. But now dns_found_answer() has a separate
orig_query_type argument to tell what kind of query it is, so there's
no need to freak out.
* If there's an IPv4 and an IPv6 address, return both in the resolved
cell.
* Treat all resolve requests as permitting IPv6, since by the spec they're
allowed to, and by the code that won't break anything.
IPv4-only exits have an implicit "reject [::]/0", which was making
policy_is_reject_star() return 1 for them, making us refuse to do
hostname lookups.
This fix chanes policy_is_reject_star() to ask about which family we meant.
The code previously detected wildcarding and replaced wildcarded
answers with DNS_STATUS_FAILED_PERMANENT. But that status variable
was no longer used! Remove the status variable, and instead change
the value of 'result' in evdns_callback.
Thank goodness for compiler warnings. In this case,
unused-but-set-variable.
Thanks to Linus for finding this one.
Now, every cached_resolve_t can remember an IPv4 result *and* an IPv6
result. As a light protection against timing-based distinguishers for
IPv6 users (and against complexity!), every forward request generates
an IPv4 *and* an IPv6 request, assuming that we're an IPv6 exit. Once
we have answers or errors for both, we act accordingly.
This patch additionally makes some useful refactorings in the dns.c
code, though there is quite a bit more of useful refactoring that could
be done.
Additionally, have a new interface for the argument passed to the
evdns_callback function. Previously, it was just the original address
we were resolving. But it turns out that, on error, evdns doesn't
tell you the type of the query, so on a failure we didn't know whether
IPv4 or IPv6 queries were failing.
The new convention is to have the first byte of that argument include
the query type. I've refactored the code a bit to make that simpler.
This makes it so we can handle getting an IPv6 in the 3 different
formats we specified it for in RESOLVED cells,
END_STREAM_REASON_EXITPOLICY cells, and CONNECTED cells.
We don't cache IPv6 addresses yet, since proposal 205 isn't
implemented.
There's a refactored function for parsing connected cells; it has unit
tests.
These options are for telling the SOCKSPort that it should allow or
not allow connections to IPv4/IPv6 addresses.
These aren't implemented yet; this is just the code to read the
options and get them into the entrey_connection_t.
Also, count ipv6 timeouts vs others. If we have too many ipv6
requests time out, then we could be degrading performance because of a
broken DNS server that ignores AAAA requests. Other cases in which
we never learn an AAAA address aren't so bad, since they don't slow
A (ipv4) answers down very much.
This is a relatively simple set of changes: we mostly need to
remove a few "but not for IPv6" changes. We also needed to tweak
the handling of DNS code to generate RESOLVED cells that could get
an IPv6 answer in return.
Now, "accept *:80" means "accept all addresses on port 80", and not
just IPv4. For just v4, say "accept *4:80"; for just v6 say "accept
*6:80".
We can parse these policies from torrc just fine, and we should be
successfully keeping them out of descriptors for now.
We also now include appropriate IPv6 addresses in "reject private:*"
By default, "*" means "All IPv4 addresses" with
tor_addr_parse_mask_ports, so I won't break anything. But if the new
EXTENDED_STAR flag is provided, then * means "any address", *4 means
"any IPv4 address" (that is, 0.0.0.0/0), and "*6" means "any IPv6
address" (that is, [::]/0).
This is going to let us have a syntax for specifying exit policies in
torrc that won't drive people mad.
Also, add a bunch of unit tests for tor_addr_parse_mask_ports to test
these new features, and to increase coverage.
We'd like these functions to be circuit-relative so that we can
implement a per-circuit DNS cache and per-circuit DNS cache rules for
proposal 205 or its successors. I'm doing this now, as a part of the
IPv6 exits code, since there are about to be a few more instances
of code using this.
This is the simplest possible workaround: make it safe to call
circuit_cell_queue_clear() on a non-attached circuit, and make it
safe-but-a-LD_BUG-warning to call update_circuit_on_cmux() on a
non-attached circuit.
LocalWords: unstage src Untracked
Apparently some compilers like to eliminate memset() operations on
data that's about to go out-of-scope. I've gone with the safest
possible replacement, which might be a bit slow. I don't think this
is critical path in any way that will affect performance, but if it
is, we can work on that in 0.2.4.
Fixes bug 7352.
There is probably no code that can write the 2 bytes at the end of the
packed_cell_t when the cell is only a 512-byte cell, but let's not get
overconfident there.
Instead of warning about low ports that are advertised, we should have
been warning about low ports that we're listening on. Bug 7285, fix
on 0.2.3.9-alpha.
That's not where I'd want to put a $, but apparently the other
foo/id/<identity> things allow it, as does an arguably valid
interpretation of control-spec.txt. So let's be consistent.
Fix for a piece of bug 7059.
We still want to build on compilers w/o c99 support, such as
(notoriously, shamefully) MSVC.
So I'm commenting out the designated initializers in
circuitmux_ewma.c. The alternative would have been to use some kind
of macros to use designated initializers only when they're
supported, but that's error-prone, and can lead to code having
different meanings under different compilers.
Bug 7286; fix on 0.2.4.4-alpha; spotted by Gisle Vanem.
If we completed the handshake for the v2 link protocol but wound up
negotiating the wong protocol version, we'd become so confused about
what part of the handshake we were in that we'd promptly die with an
assertion.
This is a fix for CVE-2012-2250; it's a bugfix on 0.2.3.6-alpha.
All servers running that version or later should really upgrade.
Bug and fix from "some guy from France." I tweaked his code slightly
to make it log the IP of the offending node, and to forward-port it to
0.2.4.
If we completed the handshake for the v2 link protocol but wound up
negotiating the wong protocol version, we'd become so confused about
what part of the handshake we were in that we'd promptly die with an
assertion.
This is a fix for CVE-2012-2250; it's a bugfix on 0.2.3.6-alpha.
All servers running that version or later should really upgrade.
Bug and fix from "some guy from France." I tweaked his code slightly
to make it log the IP of the offending node.
Clients now consider the ClientRejectInternalAddresses config option
when using a microdescriptor consensus stanza to decide whether
an exit relay would allow exiting to an internal address. Fixes
bug 7190; bugfix on 0.2.3.1-alpha.
Our implementation of parse_short_policy was screwed up: it would
ignore the last character of every short policy. Obviously, that's
broken.
This patch fixes the busted behavior, and adds a bunch of unit tests
to make sure the rest of that function is okay.
Fixes bug 7192; fix on 0.2.3.1-alpha.
Conflicts:
src/or/circuitbuild.c
There was a huge-looking conflict in circuitbuild.c, but the only
change that had been made to circuitbuild.c since I forked off the
split_circuitbuild branch was 17442560c4. So I took the
split_circuitbuild version of the conflicting part, and manually
re-applied the change from 17442560c44e8093f9a..
Failure to do so left us open to a remotely triggerable assertion
failure. Fixes CVE-2012-2249; bugfix on 0.2.3.6-alpha. Reported by
"some guy from France".
This patch is a forward-port to 0.2.4, to work with the new channel
logic.
Failure to do so left us open to a remotely triggerable assertion
failure. Fixes CVE-2012-2249; bugfix on 0.2.3.6-alpha. Reported by
"some guy from France".
We were calling channel_get_actual_remote_descr() before we used the
output of a previous channel_get_canonical_remote_descr(), thus
invalidating its output.
When we merged the channel code, we made the 'address' field of linked
directory connections created with begindir (and their associated edge
connections) contain an address:port string, when they should only
have contained the address part.
This patch also tweaks the interface to the get_descr method of
channels so that it takes a set of flags rather than a single flag.
In 4768c0efe3 (not in any released
version of Tor), we removed a little block of code that set the addr
field of an exit connection used in making a tunneled directory
request. Turns out that wasn't right.
In C, we technically aren't supposed to define our own things that
start with an underscore.
This is a purely machine-generated commit. First, I ran this script
on all the headers in src/{common,or,test,tools/*}/*.h :
==============================
use strict;
my %macros = ();
my %skipped = ();
FILE: for my $fn (@ARGV) {
my $f = $fn;
if ($fn !~ /^\.\//) {
$f = "./$fn";
}
$skipped{$fn} = 0;
open(F, $fn);
while (<F>) {
if (/^#ifndef ([A-Za-z0-9_]+)/) {
$macros{$fn} = $1;
next FILE;
}
}
}
print "#!/usr/bin/perl -w -i -p\n\n";
for my $fn (@ARGV) {
if (! exists $macros{$fn}) {
print "# No macro known for $fn!\n" if (!$skipped{$fn});
next;
}
if ($macros{$fn} !~ /_H_?$/) {
print "# Weird macro for $fn...\n";
}
my $goodmacro = uc $fn;
$goodmacro =~ s#.*/##;
$goodmacro =~ s#[\/\-\.]#_#g;
print "s/(?<![A-Za-z0-9_])$macros{$fn}(?![A-Za-z0-9_])/TOR_${goodmacro}/g;\n"
}
==============================
It produced the following output, which I then re-ran on those same files:
==============================
s/(?<![A-Za-z0-9_])_TOR_ADDRESS_H(?![A-Za-z0-9_])/TOR_ADDRESS_H/g;
s/(?<![A-Za-z0-9_])_TOR_AES_H(?![A-Za-z0-9_])/TOR_AES_H/g;
s/(?<![A-Za-z0-9_])_TOR_COMPAT_H(?![A-Za-z0-9_])/TOR_COMPAT_H/g;
s/(?<![A-Za-z0-9_])_TOR_COMPAT_LIBEVENT_H(?![A-Za-z0-9_])/TOR_COMPAT_LIBEVENT_H/g;
s/(?<![A-Za-z0-9_])_TOR_CONTAINER_H(?![A-Za-z0-9_])/TOR_CONTAINER_H/g;
s/(?<![A-Za-z0-9_])_TOR_CRYPTO_H(?![A-Za-z0-9_])/TOR_CRYPTO_H/g;
s/(?<![A-Za-z0-9_])TOR_DI_OPS_H(?![A-Za-z0-9_])/TOR_DI_OPS_H/g;
s/(?<![A-Za-z0-9_])_TOR_MEMAREA_H(?![A-Za-z0-9_])/TOR_MEMAREA_H/g;
s/(?<![A-Za-z0-9_])_TOR_MEMPOOL_H(?![A-Za-z0-9_])/TOR_MEMPOOL_H/g;
s/(?<![A-Za-z0-9_])TOR_PROCMON_H(?![A-Za-z0-9_])/TOR_PROCMON_H/g;
s/(?<![A-Za-z0-9_])_TOR_TORGZIP_H(?![A-Za-z0-9_])/TOR_TORGZIP_H/g;
s/(?<![A-Za-z0-9_])_TOR_TORINT_H(?![A-Za-z0-9_])/TOR_TORINT_H/g;
s/(?<![A-Za-z0-9_])_TOR_LOG_H(?![A-Za-z0-9_])/TOR_TORLOG_H/g;
s/(?<![A-Za-z0-9_])_TOR_TORTLS_H(?![A-Za-z0-9_])/TOR_TORTLS_H/g;
s/(?<![A-Za-z0-9_])_TOR_UTIL_H(?![A-Za-z0-9_])/TOR_UTIL_H/g;
s/(?<![A-Za-z0-9_])_TOR_BUFFERS_H(?![A-Za-z0-9_])/TOR_BUFFERS_H/g;
s/(?<![A-Za-z0-9_])_TOR_CHANNEL_H(?![A-Za-z0-9_])/TOR_CHANNEL_H/g;
s/(?<![A-Za-z0-9_])_TOR_CHANNEL_TLS_H(?![A-Za-z0-9_])/TOR_CHANNELTLS_H/g;
s/(?<![A-Za-z0-9_])_TOR_CIRCUITBUILD_H(?![A-Za-z0-9_])/TOR_CIRCUITBUILD_H/g;
s/(?<![A-Za-z0-9_])_TOR_CIRCUITLIST_H(?![A-Za-z0-9_])/TOR_CIRCUITLIST_H/g;
s/(?<![A-Za-z0-9_])_TOR_CIRCUITMUX_EWMA_H(?![A-Za-z0-9_])/TOR_CIRCUITMUX_EWMA_H/g;
s/(?<![A-Za-z0-9_])_TOR_CIRCUITMUX_H(?![A-Za-z0-9_])/TOR_CIRCUITMUX_H/g;
s/(?<![A-Za-z0-9_])_TOR_CIRCUITUSE_H(?![A-Za-z0-9_])/TOR_CIRCUITUSE_H/g;
s/(?<![A-Za-z0-9_])_TOR_COMMAND_H(?![A-Za-z0-9_])/TOR_COMMAND_H/g;
s/(?<![A-Za-z0-9_])_TOR_CONFIG_H(?![A-Za-z0-9_])/TOR_CONFIG_H/g;
s/(?<![A-Za-z0-9_])TOR_CONFPARSE_H(?![A-Za-z0-9_])/TOR_CONFPARSE_H/g;
s/(?<![A-Za-z0-9_])_TOR_CONNECTION_EDGE_H(?![A-Za-z0-9_])/TOR_CONNECTION_EDGE_H/g;
s/(?<![A-Za-z0-9_])_TOR_CONNECTION_H(?![A-Za-z0-9_])/TOR_CONNECTION_H/g;
s/(?<![A-Za-z0-9_])_TOR_CONNECTION_OR_H(?![A-Za-z0-9_])/TOR_CONNECTION_OR_H/g;
s/(?<![A-Za-z0-9_])_TOR_CONTROL_H(?![A-Za-z0-9_])/TOR_CONTROL_H/g;
s/(?<![A-Za-z0-9_])_TOR_CPUWORKER_H(?![A-Za-z0-9_])/TOR_CPUWORKER_H/g;
s/(?<![A-Za-z0-9_])_TOR_DIRECTORY_H(?![A-Za-z0-9_])/TOR_DIRECTORY_H/g;
s/(?<![A-Za-z0-9_])_TOR_DIRSERV_H(?![A-Za-z0-9_])/TOR_DIRSERV_H/g;
s/(?<![A-Za-z0-9_])_TOR_DIRVOTE_H(?![A-Za-z0-9_])/TOR_DIRVOTE_H/g;
s/(?<![A-Za-z0-9_])_TOR_DNS_H(?![A-Za-z0-9_])/TOR_DNS_H/g;
s/(?<![A-Za-z0-9_])_TOR_DNSSERV_H(?![A-Za-z0-9_])/TOR_DNSSERV_H/g;
s/(?<![A-Za-z0-9_])TOR_EVENTDNS_TOR_H(?![A-Za-z0-9_])/TOR_EVENTDNS_TOR_H/g;
s/(?<![A-Za-z0-9_])_TOR_GEOIP_H(?![A-Za-z0-9_])/TOR_GEOIP_H/g;
s/(?<![A-Za-z0-9_])_TOR_HIBERNATE_H(?![A-Za-z0-9_])/TOR_HIBERNATE_H/g;
s/(?<![A-Za-z0-9_])_TOR_MAIN_H(?![A-Za-z0-9_])/TOR_MAIN_H/g;
s/(?<![A-Za-z0-9_])_TOR_MICRODESC_H(?![A-Za-z0-9_])/TOR_MICRODESC_H/g;
s/(?<![A-Za-z0-9_])_TOR_NETWORKSTATUS_H(?![A-Za-z0-9_])/TOR_NETWORKSTATUS_H/g;
s/(?<![A-Za-z0-9_])_TOR_NODELIST_H(?![A-Za-z0-9_])/TOR_NODELIST_H/g;
s/(?<![A-Za-z0-9_])_TOR_NTMAIN_H(?![A-Za-z0-9_])/TOR_NTMAIN_H/g;
s/(?<![A-Za-z0-9_])_TOR_ONION_H(?![A-Za-z0-9_])/TOR_ONION_H/g;
s/(?<![A-Za-z0-9_])_TOR_OR_H(?![A-Za-z0-9_])/TOR_OR_H/g;
s/(?<![A-Za-z0-9_])_TOR_POLICIES_H(?![A-Za-z0-9_])/TOR_POLICIES_H/g;
s/(?<![A-Za-z0-9_])_TOR_REASONS_H(?![A-Za-z0-9_])/TOR_REASONS_H/g;
s/(?<![A-Za-z0-9_])_TOR_RELAY_H(?![A-Za-z0-9_])/TOR_RELAY_H/g;
s/(?<![A-Za-z0-9_])_TOR_RENDCLIENT_H(?![A-Za-z0-9_])/TOR_RENDCLIENT_H/g;
s/(?<![A-Za-z0-9_])_TOR_RENDCOMMON_H(?![A-Za-z0-9_])/TOR_RENDCOMMON_H/g;
s/(?<![A-Za-z0-9_])_TOR_RENDMID_H(?![A-Za-z0-9_])/TOR_RENDMID_H/g;
s/(?<![A-Za-z0-9_])_TOR_RENDSERVICE_H(?![A-Za-z0-9_])/TOR_RENDSERVICE_H/g;
s/(?<![A-Za-z0-9_])_TOR_REPHIST_H(?![A-Za-z0-9_])/TOR_REPHIST_H/g;
s/(?<![A-Za-z0-9_])_TOR_REPLAYCACHE_H(?![A-Za-z0-9_])/TOR_REPLAYCACHE_H/g;
s/(?<![A-Za-z0-9_])_TOR_ROUTER_H(?![A-Za-z0-9_])/TOR_ROUTER_H/g;
s/(?<![A-Za-z0-9_])_TOR_ROUTERLIST_H(?![A-Za-z0-9_])/TOR_ROUTERLIST_H/g;
s/(?<![A-Za-z0-9_])_TOR_ROUTERPARSE_H(?![A-Za-z0-9_])/TOR_ROUTERPARSE_H/g;
s/(?<![A-Za-z0-9_])TOR_ROUTERSET_H(?![A-Za-z0-9_])/TOR_ROUTERSET_H/g;
s/(?<![A-Za-z0-9_])TOR_STATEFILE_H(?![A-Za-z0-9_])/TOR_STATEFILE_H/g;
s/(?<![A-Za-z0-9_])_TOR_STATUS_H(?![A-Za-z0-9_])/TOR_STATUS_H/g;
s/(?<![A-Za-z0-9_])TOR_TRANSPORTS_H(?![A-Za-z0-9_])/TOR_TRANSPORTS_H/g;
s/(?<![A-Za-z0-9_])_TOR_TEST_H(?![A-Za-z0-9_])/TOR_TEST_H/g;
s/(?<![A-Za-z0-9_])_TOR_FW_HELPER_H(?![A-Za-z0-9_])/TOR_TOR_FW_HELPER_H/g;
s/(?<![A-Za-z0-9_])_TOR_FW_HELPER_NATPMP_H(?![A-Za-z0-9_])/TOR_TOR_FW_HELPER_NATPMP_H/g;
s/(?<![A-Za-z0-9_])_TOR_FW_HELPER_UPNP_H(?![A-Za-z0-9_])/TOR_TOR_FW_HELPER_UPNP_H/g;
==============================
The rationale for treating these files differently is that we should
be checking upstream for changes as applicable, and merging changes
upstream as warranted.
Conflicts:
src/or/circuitbuild.c
The conflict was trivial, since no line of code actually changed in
both branches: There was a fmt_addr() that turned into fmt_addrport()
in bug7011, and a "if (!n_conn)" that turned into "if (!n_chan)" in
master.
This is mostly a conversion from this pattern:
log("... %s:%d ...", fmt_and_decorate_addr(&addr), port);
to this:
log("... %s ...", fmt_addrport(&addr, port));
The output is the same in all cases.
Apparently BridgeDB is already expecting transport lines to be formatted
thus; see https://trac.torproject.org/projects/tor/ticket/7011#comment:12 ff.
It may be that there are no extant IPv6 pluggable transport bridges yet,
so this didn't cause a problem.
state_transport_line_is_valid calls tor_addr_port_lookup, which expects
brackets around an IPv6 address. Without this, cached transport
addresses can't be parsed later:
[warn] state: Could not parse addrport.
[warn] state: State file seems to be broken.
See #7011.
It's possible for connection_or_connect() to fail and return NULL after it
sets tlschan->conn, so not checking leaves a channel hanging around in
CHANNEL_STATE_OPENING with a pointer to a freed or_connection_t forever.
Note: this is a squashed commit; see branch bug6465_rebased_v2 of user/andrea/tor.git for full history of the following 2 commits:
Use channel_t in cpuworker.c
Fix bug in channel_t usage in cpuworker.c that was killing relaying on channel_t-ized Tor. The tags passed to the worker now have a channel ID, not a connection ID.
Note: this is a squashed commit; see branch bug6465_rebased_v2 of user/andrea/tor.git for full history of the following 10 commits:
Convert relay.c/relay.h to channel_t
Updating the timestamp if n_flushed > 0 at the end of channel_flush_from_first_active_circuit() was redundant since channel_write_cell() et al. do it themselves.
Get rid of now-unnecessary time parameter in channel_flush_from_first_active_circuit()
Get rid of now-unnecessary time parameter in channel_flush_from_first_active_circuit() in connection_or.c
Add non-inlined external call for channeltls.c to free a packed_cell_t
Appease make check-spaces in relay.c
Replace channel_get_write_queue_len() with sufficient and easier to implement channel_has_queued_writes() in relay.c
Rename channel_touched_by_client() and client_used field for consistency with other timestamps in relay.c
Don't double-free packed cells in relay.c (channel_t Tor now bootstraps and works as a client)
Rearrange channel_t struct to use a union distinguishing listener from cell-bearing channels in relay.c
Note: this is a squashed commit; see branch bug6465_rebased_v2 of user/andrea/tor.git for full history of the following 90 commits:
Add channel.c/channel.h for bug 6465
Fix make check-spaces in new channel.c/channel.h
Make sure new channel.h is in nodist_HEADERS and Makefile.nmake is up to date too
Add channel_state_t and state utility functions
Add channel_change_state()
Better comments in channel.h
Add CHANNEL_STATE_LISTENING for channel_t
Fix wide line in channel.c
Add structures/prototypes for incoming cell handling
Implement channel_queue_cell() and channel_queue_var_cell()
Implement channel_process_cells()
Fix asserts in channel_queue_cell() and channel_queue_var_cell()
Add descriptive comments for channel_queue_cell() and channel_queue_var_cell()
Implement channel cell handler getters/setters
Queue outgoing writes when not in writeable state
Drain queues and test assertions when changing channel_t state
Add log_debug() messages for channel_t stuff
Add log_debug() messages for channel_t stuff
Add some channel_t metadata
Add time_t client_used to channel_t
Add channel_touched_by_client()
Declare a few channel_t metadata queries we'll have to implement later for use by circuitbuild.c
Add next_circ_id/circ_id_type to channel_t for use by circuitbuild.c
Count n_circuits in channel_t
Channel timestamp calls
Add create timestamp for channel.h
Declare some new metadata queries on channel_t
Add get_real_remote_descr() prototype
Move active_circuits stuff to channel_t, some other or.h and channel.h changes
Make channel_t refcounted and use global lists of active channels
Update channel_request_close() and channel_change_state() for channel_t registration mechanism
Handle closing channels sensibly
Add global_identifier for channels, channel_init() internal use function
Add timestamp_last_added_nonpadding to channel_t
Better comments in channel_init()
Correctly handle next_circ_id in channel_init()
Correctly handle next_circ_id in channel_init() and even compile this time
Appease make check-spaces
Update timestamps when writing cells to channel_t
Add channel_flush_some_cells() to call channel_flush_from_first_active_circuit()
Add registered channel lookup functions
Get rid of client_used in or_connection_t; it's in channel_t now
Get rid of circ_id_type in or_connection_t; implement channel_set_circ_id_type()
Eliminate is_bad_for_new_circs in or_connection_t; implement getter/setter for it in channel_t
Eliminate next_circ_id in or_connection_t in favor of channel_t
Handle packed cells in channel_t for relay.c
Add channel_identity_map and related functions
Handle add/remove from channel identity map on state transitions
Implement channel_is_local() and channel_mark_local()
Implement channel_is_client() and channel_mark_client()
Implement channel_is_outgoing() and channel_mark_outgoing()
Eliminate declaration for redundant channel_nonopen_was_started_here()
Add channel timestamps
Add channel timestamps, fix some make-check-spaces complaints
Remove redundant channel_was_started_here() function and initiated_remotely bit
Rename channel_get_remote_descr()/channel_get_real_remote_descr() to something clearer in channel.h
Replace channel_get_write_queue_len() with sufficient and easier to implement channel_has_queued_writes() in channel.h
Change return type of channel_is_bad_for_new_circs() to int for consistency
Implement channel_has_queued_writes()
Rename channel_touched_by_client() and client_used field for consistency with other timestamps in channel.{c,h}
Implement channel_get_actual_remote_descr() and channel_get_canonical_remote_descr() in channel.{c,h}
Implement channel_matches_extend_info() in channel.{c,h}
Implement channel_get_for_extend() and channel_is_better() in channel.{c,h}
Make channel_is_better() public in channel.{c,h}
Implement channel_matches_target_addr_for_extend() in channel.{c,h}
Implement channel_is_canonical_is_reliable() in channel.{c,h}
Demoronize get_remote_descr() method prototype - what the hell was I thinking there?
Timestamp channels in the right places in channel.c
Add missing tor_assert() in channel.c
Check if the lower layer accepted a cell in channel_write_cell() et al. of channel.c
Implement channel_flush_cells() in channel.c (w00t, it builds at last)
Call channel_timestamp_drained() at the right places in channel.c
Implement channel_run_cleanup()
Support optional channel_get_remote_addr() method and use it for GeoIP in channel_do_open_actions()
Get rid of channel refcounting; it'll be too complicated to handle it properly with all the pointers from circuits to channels, and closing from channel_run_cleanup() will work okay just like with connections
Doxygenate channel.c
Appease make check-spaces in channel.c
Fix superfluous semicolons in channel.c
Add/remove channels from identity digest map in all the right places in channel.c
The cell queues on channel_t must be empty when going to a CLOSED or ERROR state
Appease make check-spaces in channel.c
Add channel_clear/set_identity_digest() and some better logging to channel.{c,h}
Fix better logging to channel.c
Avoid SIGSEGV testing for queue emptiness in channel_flush_some_cells_from_outgoing_queue()
Remove TODO about checking cell queue in channel_free(); no need for it
Appease make check-spaces in channel.c
Add channel_free_all() and support functions
Check nullness of active_circuit_pqueue in channel_free()
Fix SMARTLIST_FOREACH_END usage in channel_process_cells()
Rearrange channel_t struct to use a union distinguishing listener from cell-bearing channels in channel.{c,h}
They're typically redundant with the "Your computer is too slow"
messages. Fixes bug 7038; bugfix on 0.2.2.16-alpha.
(In retrospect, we should have fixed this bug back in ticket 1042.)
We used to never return an IPv6 address unless ClientUseIPv6 was
set. We should allow clients running with bridges use IPv6 OR ports
even without setting ClientUseIPv6. Configuring an IPv6 address in a
Bridge line should imply that.
Fixes th second part of #6757.
Look at the address family of the preferred OR port rather than the
node.ipv6_preferred flag since the logic has changed with new
ClientUseIPv6 config option.
Fixes ticket 6884.
Right-shifting negative values has implementation-defined behavior.
On all the platforms we work on right now, the behavior is to
sign-extend the input. That isn't what we wanted in
auth_type_val = (descriptor_cookie_tmp[16] >> 4) + 1;
Fix for 6861; bugfix on 0.2.1.5-alpha; reported pseudonymously.
The broken behavior didn't actually hurt anything, I think, since the
only way to get sign-extension to happen would be to have the top bit
of descriptor_cookie_tmp[16] set, which would make the value of
descriptor_cookie_tmp[16] >> 4 somewhere between 0b11111111 and
0b11111000 (that is, between -1 and -8). So auth_type_val would be
between -7 and 0. And the immediate next line does:
if (auth_type_val < 1 || auth_type_val > 2) {
So the incorrectly computed auth_type_val would be rejected as
invalid, just as a correctly computed auth_type_val would be.
Still, this stuff shouldn't sit around the codebase.
We were doing (1<<p) to generate a flag at position p, but we should
have been doing (U64_LITERAL(1)<<p).
Fixes bug 6861; bugfix on 0.2.0.3-alpha; reported pseudonymously.
Our flag voting code needs to handle unrecognized flags, so it stores
them in a 64-bit bitfield. But we never actually checked for too many
flags, so we were potentially doing stuff like U64_LITERAL(1)<<flagnum
with flagnum >= 64. That's undefined behavior.
Fix for bug 6833; bugfix on 0.2.0.1-alpha.
When I removed version_supports_begindir, I accidentally removed the
mechanism we had been using to make a directory cache self-test its
directory port. This caused bug 6815, which caused 6814 (both in
0.2.4.2-alpha).
To fix this bug, I'm replacing the "anonymized_connection" argument to
directory_initiate_command_* with an enumeration to say how indirectly
to connect to a directory server. (I don't want to reinstate the
"version_supports_begindir" argument as "begindir_ok" or anything --
these functions already take too many arguments.)
For safety, I made sure that passing 0 and 1 for 'indirection' gives
the same result as you would have gotten before -- just in case I
missed any 0s or 1s.
we can turn it into an autobool later if we have some way for it
to make a decision.
(patch possibly got lost when nickm merged #6770; or maybe nickm meant
for it to be this way. i'm not sure.)
Add handle_fw_helper_output(), a function responsible for parsing the
output of tor-fw-helper. Refactor tor_check_port_forwarding() and
run_scheduled_events() accordingly too.
We now issue warnings when we get control output from tor-fw-helper,
and we log the verbose output of tor-fw-helper in LOG_INFO.
Conflicts:
src/common/util.c
See #4771 for rationale.
Note that this patch does not take suggested changes in #4470 into
account and keeps treating AuthDirHasIPv6Connectivity as an
AUTOBOOL. Thus, bug fixes for that are included here as well.
This is a fix on master, unreleased as of now.
Also, make node_get_prim_orport() indicate in its return value whether
a valid OR port was copied or not.
Maybe we should make it legal to pass ap_out==NULL?
Also, do this only for clients, explicitly.
Also, give the flag a value every time we set consensus. We used to
touch it only when ClientPreferIPv6ORPort was set, which was wrong.
extend_info_from_node() used to use the primary OR port (i.e. IPv4)
unless the node had routerinfo. Now that we have IPv6 addresses in
microdescs we may want to use them.
Note that this patch changes using r->cache_info.identity_digest into
using node->identity. I count on these being well synchronised, or
things would break in other ways. Right?
Add ClientUseIPv6 and ClientPreferIPv6ORPort configuration options.
Use "preferred OR port" for all entry nodes, not only for bridges.
Mark bridges with "prefer IPv6 OR port" if an IPv6 address is
configured in Bridge line and ClientPreferIPv6ORPort is set.
Mark relays with "prefer IPv6 OR port" if an IPv6 address is found in
descriptor and ClientPreferIPv6ORPort is set.
Filter "preferred OR port" through the ClientUseIPv6 config option. We
might want to move this test to where actual connection is being set
up once we have a fall back mechanism in place.
Have only non-servers pick an IPv6 address for the first hop: We
don't want relays to connect over IPv6 yet. (IPv6 has never been used
for second or third hops.)
Implements ticket 5535.
Generate and store all supported microdescriptor formats. Generate
votes with one "m" line for each format. Only "m" lines with version
info matching chosen consensus method will be voted upon.
An optimisation would be to combine "m" lines with identical hashes,
i.e. instead of "m 1,2,3 H1" and "m 4,5 H1", say "m 1,2,3,4,5 H1".
Define new new consensus method 14 adding "a" lines to vote and
consensus documents.
From proposal 186:
As with other data in the vote derived from the descriptor, the
consensus will include whichever set of "a" lines are given by the
most authorities who voted for the descriptor digest that will be
used for the router.
This patch implements this.
Allow one-hop directory fetching circuits the full "circuit build timeout"
period, rather than just half of it, before failing them and marking
the relay down. This fix should help reduce cases where clients declare
relays (or worse, bridges) unreachable because the TLS handshake takes
a few seconds to complete.
Fixes bug 6743 (one piece of bug 3443); bugfix on 0.2.2.2-alpha, where
we changed the timeout from a static 30 seconds.
We've had over two months to fix them, and didn't. Now we need
0.2.3.x stable. Yes, it would be cool to get this working in
0.2.3.x, but not at the expense of delaying every other feature that
_does_ work in 0.2.3.x. We can do a real fix in 0.2.4.
This is important, since otherwise an attacker can use timing info
to probe the internal network.
Also, add an option (ExtendAllowPrivateAddresses) so that
TestingTorNetwork won't break.
Fix for bug 6710; bugfix on all released versions of Tor.
Move extend_info_from_router() from circuitbuild.c to router.c and
make it static.
Add get_configured_bridge_by_orports_digest() and have
get_configured_bridge_by_routerinfo() and
node_is_a_configured_bridge() use it. We now consider all OR ports of
a bridge when looking for it.
Move node_get_*_orport to nodelist.c.
Fix a cut'n'paste error in header of nodelist.h.
Add node_assert_ok().
Add router_get_all_orports(). It's duplicating code from
node_get_all_orports(). Worth fixing at the cost of complicating the
API slightly?
There was some code in the "err:" block that would always log a
warning, reporting an "unknown error" if we hadn't set err_msg. But
there were also plenty of "goto err" blocks that did their own
logging, and never set err_msg at all. Now we should only log when
we have an error message to log.
This fixes bug 6638, from no released Tor version.
Failure to do this would lead to double-free cases and similar,
especially when the exit's DNS was broken. See bug 6472 for full
details; this is a fix for 6472.
Anonymous patch from "cypherpunks" on trac.
Long ago, before we had cell queues, it was necessary to maybe call
connection_handle_write() from connectino_write_to_buf_impl() on OR
connections, so that we wouldn't get into a loop of reading infinite
amounts of data and queueing it all on an outbuf before bothering to
write any data.
If that doesn't sounds like what our code does now, you're right:
right now, we won't stick more than OR_CONN_HIGHWATER bytes of cells
on an outbuf, and we won't suck more than CELL_QUEUE_HIGHWATER_SIZE
cells off any edge connection. So, there's no more call for that
code.
Removing this code will simplify our data flow, and that should be
something we can all get behind.
This is done to avoid spurious warns. Additional log lines are also
added to try to track down the codepaths where we are somehow overcounting
success counts.
This patch extracts the inner part of config_register_addressmaps --
the part that knows about detecting wildcard addresses addresses --
and makes it into a new function. The new function is deliberately
not moved or reindented, so that the diff is smaller.
I need this to fix bug 6244.
Extend cells aren't allowed to have a stream_id, but we were only
blocking them when they had a stream_id that corresponded to a
connection. As far as I can tell, this change is harmless: it will
make some kinds of broken clients not work any more, but afaik nobody
actually make a client that was broken in that way.
Found while hunting for other places where we made the same mistake
as in 6271.
Bugfix on d7f50337c1 back from May 2003, which introduced
telescoping circuit construction into 0.0.2pre8.
Thanks to the changes we started making with SocksPort and friends
in 0.2.3.3-alpha, any of our code that did "if (options->Sockport)"
became wrong, since "SocksPort 0" would make that test true whereas
using the default SocksPort value would make it false. (We didn't
actually do "if (options->SockPort)" but we did have tests for
TransPort. When we moved DirPort, ORPort, and ControlPort over to
the same system in 0.2.3.9-alpha, the problem got worse, since our
code is littered with checks for DirPort and ORPort as booleans.
This code renames the current linelist-based FooPort options to
FooPort_lines, and adds new FooPort_set options which get set at
parse-and-validate time on the or_options_t. FooPort_set is true
iff we will actually try to open a listener of the given type. (I
renamed the FooPort options rather than leave them alone so that
every previous user of a FooPort would need to get inspected, and so
that any new code that forgetfully uses FooPort will need fail to
compile.)
Fix for bug 6507.
With this patch, I dump the old kludge of using magic negative
numbers to indicate unknown bandwidths. I also compute each node's
weighted bandwidth exactly once, rather than computing it once in
a loop to compute the total weighted bandwidth and a second time in
a loop to find which one we picked.
Previously, we had incremented rand_bw so that when we later tested
"tmp >= rand_bw", we wouldn't have an off-by-one error. But instead,
it makes more sense to leave rand_bw alone and test "tmp > rand_bw".
Note that this is still safe. To take the example from the bug1203
writeup: Suppose that we have 3 nodes with bandwidth 1. So the
bandwidth array is { 1, 1, 1 }, and the total bandwidth is 3. We
choose rand_bw == 0, 1, or 2. With the first iteration of the loop,
tmp is now 1; with the second, tmp is 2; with the third, tmp is 3.
Now that our check is tmp > rand_bw, we will set i in the first
iteration of the loop iff rand_bw == 0; in the second iteration of
the loop iff rand_bw == 1, and in the third iff rand_bw == 2.
That's what we want.
Incidentally, this change makes the bug 6538 fix more ironclad: once
rand_bw is set to UINT64_MAX, tmp > rand_bw is obviously false
regardless of the value of tmp.
The old approach, because of its "tmp >= rand_bw &&
!i_has_been_chosen" check, would run through the second part of the
loop slightly slower than the first part. Now, we remove
i_has_been_chosen, and instead set rand_bw = UINT64_MAX, so that
every instance of the loop will do exactly the same amount of work
regardless of the initial value of rand_bw.
Fix for bug 6538.
This should make our preferred solution to #6538 easier to
implement, avoid a bunch of potential nastiness with excessive
int-vs-double math, and generally make the code there a little less
scary.
"But wait!" you say. "Is it really safe to do this? Won't the
results come out differently?"
Yes, but not much. We now round every weighted bandwidth to the
nearest byte before computing on it. This will make every node that
had a fractional part of its weighted bandwidth before either
slighty more likely or slightly less likely. Further, the rand_bw
value was only ever set with integer precision, so it can't
accurately sample routers with tiny fractional bandwidth values
anyway. Finally, doing repeated double-vs-uint64 comparisons is
just plain sad; it will involve an implicit cast to double, which is
never a fun thing.
This gives us a few benefits:
1) make -j clean all
this will start working, as it should. It currently doesn't.
2) increased parallel build
recursive make will max out at number of files in a directory,
non-recursive make doesn't have such a limitation
3) Removal of duplicate information in make files,
less error prone
I've also slightly updated how we call AM_INIT_AUTOMAKE, as the way
that was used was not only deprecated but will be *removed* in the next
major automake release (1.13).... so probably best that we can continue
to bulid tor without requiring old automake.
(see http://www.gnu.org/software/automake/manual/html_node/Public-Macros.html )
For more reasons why, see resources such as:
http://miller.emu.id.au/pmiller/books/rmch/
In 0.2.3.18-rc, we started warning on this case while building a
list of missing microdescriptor digests. That turned out to spam
the logs; instead let's warn at parse time.
Partial fix for bug 6404.
The spec requires that every router in a microdesc consensus have an
m line; we weren't obeying that spec.
This creates a new consensus method (13) to allow voting to continue
to work right. Partial fix for bug 6404; fix on 0.2.2.6-alpha.
Test for config option AuthDirPublishIPv6 == 1 rather than for running
as a bridge authority when deciding whether to care or not about IPv6
OR ports in descriptors.
Implements enhancement #6406.
We can end up in dirserv_orconn_tls_done() with a node missing
routerinfo in at least two cases -- command_process_certs_cell() and
connection_or_check_valid_tls_handshake() -- and probably more.
You can say "struct foo_t" as much as you want, but you'd better not
have "typedef struct foo_t foo_t" more than once.
Fix for bug 6416. Bug not in any released version of Tor.
This avoids a possible crash bug in flush_from_first_active_circuit.
Fixes bug 6341; bugfix on 0.2.2.7-alpha.
Bug reported and fixed by a pseudonymous user on IRC.
I only check on circuits, not streams, since bloating your stream
window past the initial circuit window can't help you much.
Also, I compare to CIRCWINDOW_START_MAX so we don't have surprising
races if we lower CIRCWINDOW_START for an experiment.
The SMARTLIST_FOREACH macro is more convenient than BEGIN/END when
you have a nice short loop body, but using it for long bodies makes
your preprocessor tell the compiler that all the code is on the same
line. That causes grief, since compiler warnings and debugger lines
will all refer to that one line.
So, here's a new style rule: SMARTLIST_FOREACH blocks need to be
short.
- Add a changes/ file.
- Make it compile under --enable-gcc-warnings.
- Update the file-level documentation of src/or/transports.c.
- Only update descriptor if at least a managed proxy was configured.
- Add our external IP address to the extra-info descriptor instead of 0.0.0.0.
This could result in bizarre window values. Report and patch
contributed pseudymously. Fixes part of bug 6271. This bug was
introduced before the first Tor release, in svn commit r152.
(bug 6271, part a.)
This reverts commit c32ec9c425.
It turns out the two sides of the circuit don't actually stay in sync,
so it is perfectly normal for the circuit window on the exit relay to
grow to 2000+. We should fix that bug and then reconsider this patch.
I only check on circuits, not streams, since bloating your stream
window past the initial circuit window can't help you much.
Also, I compare to CIRCWINDOW_START_MAX so we don't have surprising
races if we lower CIRCWINDOW_START for an experiment.
We were doing a tor_strclear() on client_keys_str when it might not
even be set.
Fix for bug 6255; bug not in any release of Tor. Thanks to katmagic
for finding this one!
The functions parse_{s,c}method_line() were using
tor_addr_port_lookup() which is capable of doing DNS lookups. DNS
lookups should not be necessary when parsing {C,S}METHOD lines.
We now catch bare {s that should be on the previous line with a do,
while, if, or for, and elses that should share a line with their
preceding }.
That is,
if (foo)
{
and
if (foo) {
...
}
else
are now detected.
We should think about maybe making Tor uncrustify-clean some day,
but configuring uncrustify is an exercise in bizarreness, and
reformatting huge gobs of Tor is always painful.
The code that detected the source of a remapped address checked that
an address mapping's source was a given rewrite rule if addr_orig had
no .exit, and addr did have a .exit after processing that rule. But
addr_orig was formatted for logging: it was not the original address
at all, but rather was the address escaped for logging and possibly
replaced with "[scrubbed]".
This new logic will correctly set ADDRMAPSRC_NONE in the case when the
address starts life as a .exit address, so that AllowDotExit can work
again.
Fixes bug 6211; bugfix on 0.2.3.17-beta
It turns out this can happen. Even though there is no reason for
connections to be marked but reading, we leave them reading anyway,
so warning here is unwarranted. Let's turn that back on once we do
something sensible and disable reading when we mark. Bugfix for
6203 on Tor 0.2.3.17-beta.
Thanks to cypherpunks for pointing out the general stupidity of the
original code here.
Now it's an orthodox "goto err/done" exit path, and it isn't some
screwy thing where we stick err/done at the end of a loop and
duplicate our cleanup code.
Previously, a directory would check the latest NS consensus for
having the signatures the client wanted, and use that consensus's
valid_until time to set the HTTP lifetime. With this patch, the
directory looks at NS consensus or the microdesc consensus,
depending on what the client asked for.
I saw 72% on a test run with 26 circuits. 70% might be a little close to the
line. That, or min_circs is too low and we need to be more patient. We still
need to test/simulate more.
The defense counts the circuit failure rate for each guard for the past N
circuits. Failure is defined as the ability to complete a first hop, but not
finish completing the circuit all the way to the exit.
If the failure rate exceeds a certain amount, a notice is emitted.
If it exceeds a greater amount, a warn is emitted and the guard is disabled.
These values are governed by consensus parameters which we intend to tune as
we perform experiments and statistical simulations.
The warning message of validate_pluggable_transports_config() is
superseded by the changes in the warning message of
connection_or_connect() when the proxy credentials can't be found.
There is a bug causing busy loops in Libevent and infinite loops in
the Shadow simulator. A connection that is marked for close, wants
to flush, is held open to flush, but is rate limited (the token
bucket is empty) triggers the bug.
This commit fixes the bug. Details are below.
This currently happens on read and write callbacks when the active
socket is marked for close. In this case, Tor doesn't actually try
to complete the read or write (it returns from those methods when
marked), but instead tries to clear the connection with
conn_close_if_marked(). Tor will not close a marked connection that
contains data: it must be flushed first. The bug occurs when this
flush operation on the marked connection can not occur because the
connection is rate-limited (its write token bucket is empty).
The fix is to detect when rate limiting is preventing a marked
connection from properly flushing. In this case, it should be
flagged as read/write_blocked_on_bandwidth and the read/write events
de-registered from Libevent. When the token bucket gets refilled, it
will check the associated read/write_blocked_on_bandwidth flag, and
add the read/write event back to Libevent, which will cause it to
fire. This time, it will be properly flushed and closed.
The reason that both read and write events are both de-registered
when the marked connection can not flush is because both result in
the same behavior. Both read/write events on marked connections will
never again do any actual reads/writes, and are only useful to
trigger the flush and close the connection. By setting the
associated read/write_blocked_on_bandwidth flag, we ensure that the
event will get added back to Libevent, properly flushed, and closed.
Why is this important? Every Shadow event occurs at a discrete time
instant. If Tor does not properly deregister Libevent events that
fire but result in Tor essentially doing nothing, Libevent will
repeatedly fire the event. In Shadow this means infinite loop,
outside of Shadow this means wasted CPU cycles.
From what I can tell, this configuration is usually a mistake, and
leads people to think that all their traffic is getting proxied when
in fact practically none of it is. Resolves the issue behind "bug"
4663.
The function is not guaranteed to NUL-terminate its output. It
*is*, however, guaranteed not to generate more than two bytes per
multibyte character (plus terminating nul), so the general approach
I'm taking is to try to allocate enough space, AND to manually add a
NUL at the end of each buffer just in case I screwed up the "enough
space" thing.
Fixes bug 5909.
