This warning would previously be given every time we tried to open a
connection to a foo.exit address, which could potentially be used to
flood the logs.  Now, we don't allow this warning to appear more
than once every 15 minutes.

Fixes bug 31466; bugfix on 0.2.2.1-alpha, when .exit was first
deprecated.

Andreas Stieger authored May 28, 2017 and Nick Mathewson committed Sep 11, 2017

Add magic comments recognized by default -Wimplicit-fallthrough=3
or break, as required.

Also add a get_options() call so it compiles.

Fixes bug 18100; bugfix on 0.2.6.3-alpha. Patch from "d4fq0fQAgoJ".

Fixes bug 21576; bugfix on Tor 0.2.9.3-alpha.
Reported by alecmuffett.

Makes 19926 less annoying in 0.2.9.  In 0.3.0, we should actually
fix this.

Fixes bug 19969; bugfix on b1d56fc5. We can fix this some more in
later Tors, but for now, this is probably the right fix for us.

This commit adds or improves the module-level documenation for:

  buffers.c circuitstats.c command.c connection_edge.c control.c
  cpuworker.c crypto_curve25519.c crypto_curve25519.h
  crypto_ed25519.c crypto_format.c dircollate.c dirserv.c dns.c
  dns_structs.h fp_pair.c geoip.c hibernate.c keypin.c ntmain.c
  onion.c onion_fast.c onion_ntor.c onion_tap.c periodic.c
  protover.c protover.h reasons.c rephist.c replaycache.c
  routerlist.c routerparse.c routerset.c statefile.c status.c
  tor_main.c workqueue.c

In particular, I've tried to explain (for each documented module)
what each module does, what's in it, what the big idea is, why it
belongs in Tor, and who calls it.  In a few cases, I've added TODO
notes about refactoring opportunities.

I've also renamed an argument, and fixed a few DOCDOC comments.

(I've done this instead of changing the semantics of
router_compare_to_my_exit_policy, because dns.c uses
router_compare_to_my_exit_policy too, in a slightly weird way.)

Previously, we would reject even rendezvous connections to IPv6
addresses when IPv6Exit was false.  But that doesn't make sense; we
don't count that as "exit"ing.  I've corrected the logic and tried
to make it a lottle more clear.

Fixes bug 18357; this code has been wrong since 9016d9e8 in
0.2.4.7-alpha.

teor (Tim Wilson-Brown) authored Jul 14, 2016 and Nick Mathewson committed Sep 13, 2016

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().

teor (Tim Wilson-Brown) authored Apr 01, 2016 and David Goulet committed Aug 24, 2016

Check NoOnionTraffic before attaching a stream.

NoOnionTraffic refuses connections to all onion hostnames,
but permits non-onion hostnames and IP addresses.

teor (Tim Wilson-Brown) authored Apr 01, 2016 and David Goulet committed Aug 24, 2016

Check NoDNSRequest, NoIPv4Traffic, and NoIPv6Traffic before
attaching a stream.

NoDNSRequest refuses connections to all non-onion hostnames,
but permits IP addresses.
NoIPv4Traffic refuses connections to IPv4 addresses, but resolves
hostnames.
NoIPv6Traffic refuses connections to IPv6 addresses, but resolves
hostnames.

Combined, they refuse all non-onion hostnames and IP addresses.

teor (Tim Wilson-Brown) authored Apr 01, 2016 and David Goulet committed Aug 24, 2016

Tor2Web refuses non-onion hostnames and IP addresses.

These functions were there so that we could abstract the differences
between evbuffer and buf_t.  But with the bufferevent removal, this
no longer serves a purpose.

This is another way that we had bufferevents-only code marked.

These appeared on some of the Jenkins platforms. Apparently some
GCCs care when you shadow globals, and some don't.

This is a partial fix for 18902.

So, back long ago, XXX012 meant, "before Tor 0.1.2 is released, we
had better revisit this comment and fix it!"

But we have a huge pile of such comments accumulated for a large
number of released versions!  Not cool.

So, here's what I tried to do:

  * 0.2.9 and 0.2.8 are retained, since those are not yet released.

  * XXX+ or XXX++ or XXX++++ or whatever means, "This one looks
    quite important!"

  * The others, after one-by-one examination, are downgraded to
    plain old XXX.  Which doesn't mean they aren't a problem -- just
    that they cannot possibly be a release-blocking problem.

Patch from icanhasaccount; closes 18462.

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.

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.

This might also be what #17752 needs.

Fixes #17876

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).

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.