[tor-bugs] #9462 [BridgeDB]: BridgeDB does some strange things when parsing bridge descriptors
Tor Bug Tracker & Wiki
blackhole at torproject.org
Mon Aug 12 23:06:55 UTC 2013
#9462: BridgeDB does some strange things when parsing bridge descriptors
-------------------------+--------------------------------------------------
Reporter: isis | Owner: isis
Type: defect | Status: accepted
Priority: normal | Milestone:
Component: BridgeDB | Version:
Keywords: descriptors | Parent:
Points: | Actualpoints:
-------------------------+--------------------------------------------------
Comment(by sysrqb):
Replying to [ticket:9462 isis]:
> Some of this stuff I am not sure if it was part of some super old
proposal for some descriptor type. Other stuff is just janky. For example,
[https://gitweb.torproject.org/user/isis/bridgedb.git/blob/HEAD:/lib/bridgedb/Bridges.py#l469
one of the bugs I just found], on L469 in lib/bridgedb/Bridges.py,
wouldn't ever get hit because to my knowledge BridgeDB has never handed
out fingerprints. But if it were to, with those lines, it would hand out
PT bridges that look like this:
>
> {{{
> bridge obfs3 1.2.3.4:5555 keyid=0123456789abcdef0123456789abcdef01234567
> }}}
>
> with the part after `keyid=` being the bridge's fingerprint.
>
This seems wrong, but there was a time when BridgeDB did hand out a
bridge's ip addr:port and its fingerprint. As I understand it, the
fingerprint option was disabled about 2 years ago (or so).
> Another thing which I am currently looking into is BridgeDB's parsing of
the networkstatus files, it seems BridgeDB expects there to ''always'' be
an `a` line with the ORaddress, whereas this is only the case if the
bridge has at least one IPv6 address.
>
> BridgeDB also seems to think that a bridge/relay can't have more than 8
ORaddress:ORport pairs. I remember this discussed years ago, though I
thought it was 16, and I don't recall if it was ever implemented in
little-t tor.
>
We limit it to 8, but really the BA will not process more than 2, iirc.
> In short, there is quite a bit of jankiness in BridgeDB's descriptor
parsing. I am going to continue fixing things and referencing dir-spec.txt
when there is a discrepancy, and just calling BridgeDB out when there
appears to be no sane reason for something referenced in any of torspec.
You should also see #9380 :) I already have a branch for this, which you
can use.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9462#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list