Roger Dingledine [Wed, 31 Jan 2018 08:21:27 +0000 (03:21 -0500)]
stop calling channel_mark_client in response to a create_fast
since all it does is produce false positives
this commit should get merged into 0.2.9 and 0.3.0 *and* 0.3.1, even
though the code in the previous commit is already present in 0.3.1. sorry
for the mess.
Roger Dingledine [Wed, 31 Jan 2018 08:21:27 +0000 (03:21 -0500)]
stop calling channel_mark_client in response to a create_fast
since all it does is produce false positives
this commit should get merged into 0.2.9 and 0.3.0 *and* 0.3.1, even
though the code in the previous commit is already present in 0.3.1. sorry
for the mess.
Roger Dingledine [Tue, 30 Jan 2018 23:05:39 +0000 (18:05 -0500)]
backport to make channel_is_client() accurate
This commit takes a piece of commit af8cadf3a9 and a piece of commit 46fe353f25, with the goal of making channel_is_client() be based on what
sort of connection handshake the other side used, rather than seeing
whether the other side ever sent a create_fast cell to us.
David Goulet [Fri, 2 Feb 2018 13:48:34 +0000 (08:48 -0500)]
sched: When releasing a channel, do not BUG() if absent from the pending list
The current code flow makes it that we can release a channel in a PENDING
state but not in the pending list. This happens while the channel is being
processed in the scheduler loop.
Fixes #25125
Signed-off-by: David Goulet <dgoulet@torproject.org>
David Goulet [Wed, 31 Jan 2018 19:15:02 +0000 (14:15 -0500)]
ns: Add a before and after consensus has changed notification
In 0.3.2.1-alpha, we've added notify_networkstatus_changed() in order to have
a way to notify other subsystems that the consensus just changed. The old and
new consensus are passed to it.
Before this patch, this was done _before_ the new consensus was set globally
(thus NOT accessible by getting the latest consensus). The scheduler
notification was assuming that it was set and select_scheduler() is looking at
the latest consensus to get the parameters it might needs. This was very wrong
because at that point it is still the old consensus set globally.
This commit changes the notify_networkstatus_changed() to be the "before"
function and adds an "after" notification from which the scheduler subsystem
is notified.
David Goulet [Wed, 31 Jan 2018 15:58:11 +0000 (10:58 -0500)]
hs-v3: Remove a BUG() when storing a descriptor in the client cache
It is possible in normal circumstances that a client fetches a descriptor
that has a lower revision counter than the one in its cache. This can happen
due to HSDir desync.
Fixes #24976
Signed-off-by: David Goulet <dgoulet@torproject.org>
David Goulet [Wed, 31 Jan 2018 16:08:33 +0000 (11:08 -0500)]
ns: Call notify_networkstatus_changed() after the new consensus is set globally
In 0.3.2.1-alpha, we've added this function in order to have a way to notify
other subsystems that the consensus just changed. The old consensus and the
new one are passed to it.
Before this patch, this was done _before_ the new consensus was set globally
(thus NOT accessible by getting the latest consensus). The scheduler
notification was assuming that it was set and select_scheduler() is looking at
the latest consensus to get the parameters it might needs. This was very wrong
because at that point it is still the old consensus set globally.
With this commit, notify_networkstatus_changed() has been moved _after_ the
new consensus is set globally. The main obvious reasons is to fix the bug
described above and in #24975. The other reason is that this notify function
doesn't return anything which could be allowing the possibility of refusing to
set the new consensus on error. In other words, the new consensus is set right
after the notification whatever happens.
It does no harm or change in behavior to set the new consensus first and then
notify the subsystems. The two functions currently used are for the control
port using the old and new consensus and sending the diff. The second is the
scheduler that needs the new consensus to be set globally before being called.
Of course, the function has been documented accordinly to clearly state it is
done _after_ the new consensus is set.
Fixes #24975
Signed-off-by: David Goulet <dgoulet@torproject.org>
Nick Mathewson [Tue, 23 Jan 2018 14:23:21 +0000 (09:23 -0500)]
Make Tor support TLS1.3 ciphers with OpenSSL 1.1.1
Without this patch, not only will TLS1.3 not work with Tor, but
OpenSSL 1.1.1 with TLS1.3 enabled won't build any connections at
all: It requires that either TLS1.3 be disabled, or some TLS1.3
ciphersuites be listed.
Taylor Yu [Wed, 10 Jan 2018 20:52:04 +0000 (14:52 -0600)]
Work around Travis CI ptrace regression
Travis CI deployed a change that disables ptrace capabilities in
container builds, which prevents LeakSanitizer on clang from working
properly. Set "sudo: required" to force non-container builds for
clang and work around this.
Taylor Yu [Wed, 10 Jan 2018 20:52:04 +0000 (14:52 -0600)]
Work around Travis CI ptrace regression
Travis CI deployed a change that disables ptrace capabilities in
container builds, which prevents LeakSanitizer on clang from working
properly. Set "sudo: required" to force non-container builds for
clang and work around this.
Roger Dingledine [Tue, 16 Jan 2018 03:33:40 +0000 (22:33 -0500)]
Remove false positives from channel_is_client()
Fix a set of false positives where relays would consider connections
to other relays as being client-only connections (and thus e.g.
deserving different link padding schemes) if those relays fell out
of the consensus briefly.
Now we look only at the initial handshake and whether the connection
authenticated as a relay.
projects / thirdparty / tor.git / log
