To hit this leak, you need to be a relay that gets a RESOLVE request
or an exit node getting a BEGIN or RESOLVE request. You must either
have unconfigured (and unconfigurable) nameservers, or you must have
somehow set DisableNetwork after a network request arrived but
before you managed to process it.
So, I doubt this is reached often. Still, a leak's a leak. Fix for
bug 5916; bugfix on 0.2.3.9-alpha and 0.1.2.1-alpha.
(When the correct answer is given in terms of seconds since the
epoch, it's hard to be sure that it really is the right answer
just by reading the code.)
* It seems parse_http_time wasn't parsing correctly any date with commas (RFCs
1123 and 850). Fix that.
* It seems parse_http_time was reporting the wrong month (they start at 0, not
1). Fix that.
* Add some tests for parse_http_time, covering all three formats.
Silences the log message:
[warn] {BUG} _connection_mark_unattached_ap(): Bug: stream (marked at connection_edge.c:2224) sending two socks replies?
after the client triggered the "Tor is not an HTTP Proxy" response.
No additional socks reply was sent, though.
Previously, we only did this check at startup, which could lead to
us holding a guard indefinitely, and give weird results. Fixes bug
5380; bugfix on 0.2.1.14-rc.
(Patch by Roger; changes file and commit message by Nick)
Previously, we skipped everything that got invoked from
options_init_from_torrc. But some of the stuff in
options_act_reversible and options_act is actually important, like
reopening the logs.
Now, a SIGHUP always makes the effects of an options_set() happen,
even though the options haven't changed.
Fix for bug 5095; bugfix on 0.2.1.9-alpha, which introduced
__ReloadTorrcOnSIGHUP.
This would happen if the deliver window could become negative
because of an nonexistent connection. (Fortunately, _that_ can't
occur, thanks to circuit_consider_sending_sendme. Still, if we
change our windowing logic at all, we won't want this to become
triggerable.) Fix for bug 5541. Bugfix on 4a66865d, back from
0.0.2pre14. asn found this. Nice catch, asn!
This tells the windows headers to give us definitions that didn't
exist before XP -- like the ones that we need for IPv6 support.
See bug #5861. We didn't run into this issue with mingw, since
mingw doesn't respect _WIN32_WINNT as well as it should for some of
its definitions.
