Re: [tor-bugs] #9156 [BridgeDB]: BridgeDB: Users try to add obfsbridges to their normal TBB

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#9156: BridgeDB: Users try to add obfsbridges to their normal TBB
----------------------------------------+-----------------------------------
 Reporter:  asn                         |          Owner:  isis    
     Type:  task                        |         Status:  accepted
 Priority:  normal                      |      Milestone:          
Component:  BridgeDB                    |        Version:          
 Keywords:  pt,usability,torlaucher,ui  |         Parent:          
   Points:                              |   Actualpoints:          
----------------------------------------+-----------------------------------

Comment(by isis):

 Replying to [comment:30 mcs]:
 > Replying to [comment:28 isis]:
 > >   * TBB-3.0.3a handles regular bridges (input as
 `<bridge_ipaddr>:<bridge_orport>` correctly, but only after closing and
 restarting TBB.
 >
 > Does the above comment mean that Tor Launcher needs to tell the tor
 process to start using the bridges right away?

 Yes. Before the Tor process is initialized, actually.

 > Does this scenario (add bridges while tor is up and running) work better
 with the older TBB 2.x/Vidalia?

 As far as I know, a Tor process must be started with `UseBridges 1` and at
 least one `Bridge 1.2.3.4:5555` line in its torrc to use bridges, and it
 will not work to put these lines into the torrc of an already-running Tor
 process and send a SIGHUP to it -- it must be started with the lines
 already present.

 So no, it does not work better with the older TBB-2.x and Vidalia. I think
 (?) that Vidalia forces you to restart TBB entirely if you tell it that
 you want to use bridges. I don't actually remember.

 > >   * TBB-3.0.3a doesn't handle PT bridges correctly. Specifically, it
 seems to parse the text box of user input, and strangely it inserts
 newlines after the transport name strings which it didn't understand, i.e.
 `obfs3 3.3.3.3:3333\n` becomes `obfs3\n3.3.3.3:3333\n`. If it is doing
 this parsing, perhaps it can just remove those lines entirely, because
 using the bridge on a port configured for PT-use 1) isn't going to work,
 and 2) is going to give away by a normal Tor connection the location of
 the bridge to surveilling parties and/or censors.
 > >
 > > An even better thing to do would be an "Uh-oh spaghettios. Did you
 mean to download <link_to_PT_bundle>?" and if the user responds "no"
 ''then'' strip the lines which began with PT transport name strings.
 >
 > Tor Launcher tries to be smart and accept bridge lists even when the
 newlines are missing.  See:
 > https://gitweb.torproject.org/tor-
 launcher.git/blob/fb97857c0e06eaa5d69ea4f9f7a75a330dad2331:/src/chrome/content
 /network-settings.js#l842

 I see... That is great. :)

 > But it sounds like that is a mistake.

 No, not at all! The problem is actually that it is '''overdoing''' it:
 ''extra'' newlines are being inserted ''between'' the `transport_method`
 and the `address:port`.

 > Is there a spec that indicates what BridgeDB will output?  Or can
 someone please describe the possibilities?

 Unfortunately there is not yet, because it is not yet precisely specified
 what BridgeDB should be expecting from descriptors it gets from the
 BridgeAuthority. But it is being sorted out currently. The ticket is
 #9013, if anyone has input.

 Basically, we need to specify how a Tor relay acting as a bridge writes
 the `transport` line of its `@type bridge-extra-info 1.1+` descriptor (see
 [https://metrics.torproject.org/formats.html#descriptortypes this metrics
 page] for explanations of descriptor `@types`), which will get sent to the
 BridgeAuthority, who then sends all of these to BridgeDB. BridgeDB will
 then need to parse these descriptors, and output `<something>` for TBB
 users.

 Historically, the only reason why BridgeDB added the string prefix
 `"bridge "` to the beginning of the `<something>` lines which it returned
 was because it was assumed that people would be copy+pasting these
 directly into their torrc. Vidalia freaks out if you give it, for example,
 the input `"bridge 1.2.3.4:5555"`, so we recently removed the `"bridge "`
 prefix.

 For the future, BridgeDB can give users a `<something>` which can be any
 format at all, so if there is something which is easier for TorLaucher to
 parse/handle, please say so. I am for whichever formats causes the least
 pain/overhead/parsing for all the components involved, ergo alternating
 adding in and taking away the `"bridge "` prefix in every other component
 seems ridiculous.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9156#comment:34>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs