We removed that feature in 0.2.4.2-alpha, but some comments seem to
have lingered.
I didn't add a changes/ file since this is just internal code cleanup.
(like clients do) rather than old-style router descriptors. Now bridges
will blend in with clients in terms of the circuits they build.
Fixes bug 6769; bugfix on 0.2.3.2-alpha.
Clients that use bridges were ignoring their cached microdesc-flavor
consensus files, because they only thought they should use the microdesc
flavor once they had a known-working bridge that could offer microdescs,
and at first boot no bridges are known-working.
This bug caused bridge-using clients to download a new microdesc consensus
on each startup.
Fixes bug 20269; bugfix on 0.2.3.12-alpha.
The client addr is essentially meaningless in this context (yes, it is
possible to explicitly `bind()` AF_LOCAL client side sockets to a path,
but no one does it, and there are better ways to grant that sort of
feature if people want it like using `SO_PASSCRED`).
As before, we check server protocols whenever server_mode(options)
is true and we check client protocols whenever server_mode(options)
is false.
Additionally, we now _also_ check client protocols whenever any
client port is set.
(Technically, we could just remove extend2 cell checking entirely,
since all Tor versions on our network are required to have it, but
let's keep this around as an example of How To Do It.)
(Despite the increased size of the consensus, this should have
approximately zero effect on the compressed consensus size, since
the "proto" line should be completely implied by the "v" line.)
[This is a brute-force method that potentially uses way too much
RAM. Need to rethink this a little. Right now you can DOS an
authority by saying "Foo=1-4294967295".]
Not telling the cmux would sometimes cause an assertion failure in
relay.c when we tried to get an active circuit and found an "active"
circuit with no cells.
Additionally, replace that assert with a test and a log message.
Fix for bug 20203. This is actually probably a bugfix on
0.2.8.1-alpha, specifically my code in 8b4e5b7ee9 where I
made circuit_mark_for_close_() do less in order to simplify our call
graph. Thanks to "cypherpunks" for help diagnosing.
It's a macro that calls down to a function whose behavior has been
getting progresively more complicated.... but we named it as if it
were a variable. That's not so smart. So, replace it with a
function call to a function that was just doing "return
current_consensus".
Fixes bug 20176.
Commit 41cc1f612b introduced a "dns_request"
configuration value which wasn't set to 1 for an entry connection on the
DNSPort leading to a refusal to resolve the given hostname.
This commit set the dns_request flag by default for every entry connection
made to the DNSPort.
Fixes#20109
Signed-off-by: David Goulet <dgoulet@torproject.org>
For a brief moment in networkstatus_set_current_consensus(), the old
consensus has been freed, but the node_t objects still have dead
pointers to the routerstatus_t objects within it. During that
interval, we absolutely must not do anything that would cause Tor to
look at those dangling pointers.
Unfortunately, calling the (badly labeled!) current_consensus macro
or anything else that calls into we_use_microdescriptors_for_circuits(),
can make us look at the nodelist.
The fix is to make sure we identify the main consensus flavor
_outside_ the danger zone, and to make the danger zone much much
smaller.
Fixes bug 20103. This bug has been implicitly present for AGES; we
just got lucky for a very long time. It became a crash bug in
0.2.8.2-alpha when we merged 35bbf2e4a4 to make
find_dl_schedule start looking at the consensus, and 4460feaf28
which made node_get_all_orports less (accidentally) tolerant of
nodes with a valid ri pointer but dangling rs pointer.
* Check consistency between the two single onion torrc options
* Use the more relevant option each time we check for single onion mode
* Clarify log messages
* Clarify comments
* Otherwise, no behaviour change
Tor checks that the flag matches the configured onion service anonymity.
Tor refuses to create unflagged onion service using ADD_ONION, if they
would be non-anonymous. The error is:
512 Tor is in non-anonymous onion mode
Similarly, if the NonAnonymous flag is present, and Tor has the default
anonymous onion config:
512 Tor is in anonymous onion mode
Parse the value to UseEntryNodes_option, then set UseEntryNodes before
validating options.
This way, Authorities, Tor2web, and Single Onion Services don't write
spurious "UseEntryNodes 0" lines to their configs. Document the fact that
these tor configurations ignore UseEntryNodes in the manual page.
Also reorder options validation so we modify UseEntryNodes first, then
check its value against EntryNodes.
And silence a warning about disabled UseEntryNodes for hidden services
when we're actually in non-anonymous single onion service mode.
We log this message every time we validate tor's options.
There's no need to log a duplicate in main() as well.
(It is impossible to run main() without validating our options.)
The changes in #19973 fixed ReachableAddresses being applied
too broadly, but they also broke Tor2web (somewhat unintentional)
compatibility with ReachableAddresses.
This patch restores that functionality, which makes intro and
rend point selection is consistent between Tor2web and Single Onion
Services.
Add experimental OnionServiceSingleHopMode and
OnionServiceNonAnonymousMode options. When both are set to 1, every
hidden service on a tor instance becomes a non-anonymous Single Onion
Service. Single Onions make one-hop (direct) connections to their
introduction and renzedvous points. One-hop circuits make Single Onion
servers easily locatable, but clients remain location-anonymous.
This is compatible with the existing hidden service implementation, and
works on the current tor network without any changes to older relays or
clients.
Implements proposal #260, completes ticket #17178. Patch by teor & asn.
squash! fixup! fixup! fixup! fixup! fixup! fixup! fixup! fixup! fixup! fixup! fixup! fixup! fixup! Implement Prop #260: Single Onion Services
Redesign single onion service poisoning.
When in OnionServiceSingleHopMode, each hidden service key is poisoned
(marked as non-anonymous) on creation by creating a poison file in the
hidden service directory.
Existing keys are considered non-anonymous if this file exists, and
anonymous if it does not.
Tor refuses to launch in OnionServiceSingleHopMode if any existing keys
are anonymous. Similarly, it refuses to launch in anonymous client mode
if any existing keys are non-anonymous.
Rewrite the unit tests to match and be more comprehensive.
Adds a bonus unit test for rend_service_load_all_keys().
(We check consensus method when deciding whether to assume a node is
valid. No need to check the consensus method for Running, since
we will never see a method before 13.)
Closes ticket 20001
g
The functions it warns about are:
assert, memcmp, strcat, strcpy, sprintf, malloc, free, realloc,
strdup, strndup, calloc.
Also, fix a few lingering instances of these in the code. Use other
conventions to indicate _intended_ use of assert and
malloc/realloc/etc.
Users can't run an anonymous client and non-anonymous single
onion service at the same time. We need to know whether we have
any client ports or sockets open to do this check.
When determining whether a client port (SOCKS, Trans, NATD, DNS)
is set, count unix sockets when counting client listeners. This
has no user-visible behaviour change, because these options are
set once and never read in the current tor codebase.
Don't count sockets when setting ControlPort_set, that's what
ControlSocket is for. (This will be reviewed in #19665.)
Don't count sockets when counting server listeners, because the code
that uses these options expects to count externally-visible ports.
(And it would change the behaviour of Tor.)
