Fixes bug 29922; bugfix on 0.2.9.3-alpha when we tried to capture
all these warnings. No need to backport any farther than 0.3.5,
though -- these warnings don't cause test failures before then.
This one was tricky to find because apparently it only happened on
_some_ windows builds.
And fix the documentation on the function: it does produce trailing
"="s as padding.
Also remove all checks for the return value, which were redundant anyway,
because the function never failed.
Part of 29660.
... and ed25519_public_to_base64(). Also remove all checks for the return
values, which were redundant anyway, because the functions never failed.
Part of 29960.
This test was disabled in 0.4.0 and later, but the fix in #29298 was only
merged to 0.4.1. So this test will never be re-enabled in 0.4.0.
Part of 29500.
Our monotime mocking forces us to call monotime_init() *before* we set the
mocked time value. monotime_init() thus stores the first ratchet value at
whatever the platform is at, and then we set fake mocked time to some later
value.
If monotime_init() gets a value from the host that is greater than what we
choose to mock time at for our unittests, all subsequent monotime_abosolute()
calls return zero, which breaks all unittests that depend on time moving
forward by updating mocked monotime values.
So, we need to adjust our mocked time to take the weird monotime_init() time
into account, when we set fake time.
Previously we used time(NULL) to set the Expires: header in our HTTP
responses. This made the actual contents of that header untestable,
since the unit tests have no good way to override time(), or to see
what time() was at the exact moment of the call to time() in
dircache.c.
This gave us a race in dir_handle_get/status_vote_next_bandwidth,
where the time() call in dircache.c got one value, and the call in
the tests got another value.
I'm applying our regular solution here: using approx_time() so that
the value stays the same between the code and the test. Since
approx_time() is updated on every event callback, we shouldn't be
losing any accuracy here.
Fixes bug 30001. Bug introduced in fb4a40c32c4a7e5; not in any
released Tor.
Having the numbers in those messages makes some of the unit test
unstable, by causing them to depend on the initialization order of
the naming objects.
