[tor-bugs] #19487 [Core Tor/Tor]: Meek and ReachableAddresses
Tor Bug Tracker & Wiki
blackhole at torproject.org
Mon Sep 19 16:26:01 UTC 2016
#19487: Meek and ReachableAddresses
-------------------------------------------------+-------------------------
Reporter: cypherpunks | Owner: dcf
Type: defect | Status:
| needs_revision
Priority: Medium | Milestone: Tor:
| 0.2.9.x-final
Component: Core Tor/Tor | Version: Tor:
| 0.2.8.2-alpha
Severity: Normal | Resolution:
Keywords: ipv6, bridges, pluggable- | Actual Points:
transports, regression, CoreTorTeam201609, |
review-group-9 |
Parent ID: | Points: 0.2
Reviewer: | Sponsor:
-------------------------------------------------+-------------------------
Changes (by dgoulet):
* status: needs_review => needs_revision
Comment:
In `fetch_bridge_descriptors()`, iiuc we log notice with a firewall policy
message if the bridge transport is not reachable but then we'll try
anyway. I think that will only bring confusion because why do we warn in
the first place if the firewall policy doesn't apply to transport?
Would having this be enough? That is, we only check firewall policy if
it's _not_ a transport or if we should ask directly and firewall policy
checks out?
{{{
if (!bridge->transport_name ||
(ask_bridge_directly &&
!fascist_firewall_allows_address_addr(&bridge->addr,
bridge->port,
FIREWALL_OR_CONNECTION,
0,
0))) {
}}}
And also, doesn't the `ask_bridge_directly` must really be set to `1` if
we have a transport? Not too familiar with this part of the code but I
don't think we want "fetch descriptor directly from bridge" if a transport
is set. If so, we could reinforce how `ask_bridge_directly = ...` is set I
guess?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/19487#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list