They added clock_gettime(), but with tv_nsec as a long, whereas
tv_usec is a __darwin_suseconds_t (a.k.a. 'int').  Now, why would
they do that? Are they preparing for a world where there are more
than 2 billion nanoseconds per second?  Are they planning for having
int be less than 32 bits again?  Or are they just not paying
attention to the Darwin API?

Also, they forgot to mark clock_gettime() as Sierra-only, so even
if we fixed the issue here, we'd still be stick with portability
breakage like we were for 0.2.9.

So, just disable clock_gettime() on apple.

Tor 0.2.9 has a broader range of fixes and workarounds here, but for
0.2.8, we're just going to maintain the existing behavior.

(The alternative would be to backport both
1eba0880 and
16fcbd21 , but the latter is kind of
a subtle kludge in the configure.ac script, and I'm not a fan of
backporting that kind of thing.)

(OpenSSL 1.1 makes EVP_CIPHER_CTX opaque, _and_ adds acceleration
for counter mode on more architectures.  So it won't work if we try
the older approach, and it might help if we try the newer one.)

Fixes bug 20588.

Apple is supposed to decorate their function declarations with
macros to indicate which OSX version introduced them, so that you
can tell the compiler that you want to build against certain
versions of OSX.  But they forgot to do that for clock_gettime() and
getentropy(), both of which they introduced in 10.12.

This patch adds a kludge to the configure.ac script where, if we
detect that we are targeting OSX 10.11 or earlier, we don't even probe
to see if the two offending functions are present.

Closes ticket 20235.

In our code to write public keys to a string, for some unfathomable
reason since 253f0f16, we would allocate a memory BIO, then
set the NOCLOSE flag on it, extract its memory buffer, and free it.
Then a little while later we'd free the memory buffer with
BUF_MEM_free().

As of openssl 1.1 this doesn't work any more, since there is now a
BIO_BUF_MEM structure that wraps the BUF_MEM structure.  This
BIO_BUF_MEM doesn't get freed in our code.

So, we had a memory leak!

Is this an openssl bug?  Maybe.  But our code was already pretty
silly.  Why mess around with the NOCLOSE flag here when we can just
keep the BIO object around until we don't need the buffer any more?

Fixes bug 20553; bugfix on 0.0.2pre8

fixes bug 20551; bugfix on 0.2.1.1-alpha

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

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

This is a belt-and-suspenders fix, where the earlier fix ("Ask
event_base_loop to finish when we add a pending stream") aims to respond
to new streams as soon as they arrive, and this one aims to make sure
that we definitely respond to all of the streams.

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.

no actual changes

This helps protect against bugs where any part of a buf_t's memory
is passed to a function that expects a NUL-terminated input.

It also closes TROVE-2016-10-001 (aka bug 20384).

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 8b4e5b7e where I
made circuit_mark_for_close_() do less in order to simplify our call
graph. Thanks to "cypherpunks" for help diagnosing.