This time, I follow grarpamp's suggestion and move the check for
.exit+AllowDotExit 0 to the top of connection_ap_rewrite_and_attach,
before any rewriting occurs.  This way, .exit addresses are
forbidden as they arrive from a socks connection or a DNSPort
request, and not otherwise.

It _is_ a little more complicated than that, though.  We need to
treat any .exit addresses whose source is TrackHostExits as meaning
that we can retry without that exit.  We also need to treat any
.exit address that comes from an AutomapHostsOnResolve operation as
user-provided (and thus forbidden if AllowDotExits==0), so that
transitioning from AllowDotExits==1 to AllowDotExits==0 will
actually turn off automapped .exit addresses.

Nick Mathewson authored 12 years ago and Roger Dingledine committed 12 years ago

We were doing an O(n) strlen in router_get_extrainfo_hash() for
every one we tried to parse.  Instead, have
router_get_extrainfo_hash() take the length of the extrainfo as an
argument, so that when it's called from
extrainfo_parse_from_string(), it doesn't do a strlen() over the
whole pile of extrainfos.

Conflicts:
	src/common/util.c
	src/test/test_util.c

Fix #5760

Now that the pt code logs mp->argv[0] all over the place, we need to
be sure to set up mp->argv in our tests.

Bugfix on e603692a, not in any released version.

If the authorities agreed on a sufficiently bad bwweightscale value
(<=0 or == INT32_MAX), the bandwidth algorithm could make the voters
assert while computing the consensus.

Fix for bug5786; bugfix on 0.2.2.17-alpha

See changes file for details.

Partial fix for bug 5786; fix on 0.2.2.2-alpha.

The underlying strtoX functions handle overflow by saturating and
setting errno to ERANGE.  If the min/max arguments to the
tor_parse_* functions are equal to the minimum/maximum of the
underlying type, then with the old approach, we wouldn't treat a
too-large value as genuinely broken.

Found this while looking at bug 5786; bugfix on 19da1f36 (in Tor
0.0.9), which introduced these functions.

(Note: It makes sense to use tor-gencert on Windows for testing
purposes only.  If you are a directory authority operator, and you
are contemplating running tor-gencert on a Windows box in an actual
production environment, you are probably making a mistake.)

i assume if nickm maintained "libeven" this would never have been
introduced. :)

We had been checking for EINVAL, but that means that SOCK_* isn't
supported, not that the syscall itself is missing.

Bugfix on 0.2.3.1-alpha, which started to use accept4.

This is how IPv6 says "0.0.0.0" and something we will have to
translate into a globally reachable address before putting it in a
descriptor.

The fix is a short term solution until a real one is implemented.

Closes #5146.

Nick Mathewson authored 12 years ago and Roger Dingledine committed 12 years ago

Fix for bug 5723; bugfix on 0.2.3.1-alpha (commit 22f723e4)

I think that the trailing __ got added in false analogy to
HAVE_MACRO__func__, HAVE_MACRO__FUNC__, and HAVE_MACRO__FUNCTION__.
But those macros actually indicate the presence of __func__,
__FUNC__, and __FUNCTION__ respectively.  The __ at the end of
HAVE_EXTERN_ENVIRON_DECLARED would only be appropriate if the
environ were declared__, whatever that means.

(As a side-note, HAVE_MACRO__func__ and so on should probably be
renamed HAVE_MACRO___func__ and so on.  But that can wait.)

This is an identifier renaming only.

We'd had our configure.in test include unistd.h unconditionally,
which would fail on Windows/mingw, even though environ _was_
declared there.  Fix for 5704; bugfix on 0.2.3.13-alpha.

Thanks to Erinn for finding this and rransom for figuring out the
problem.