Opened 4 years ago

Last modified 6 months ago

#16895 new enhancement

allow Tor to parse bridge information copied and pasted verbatim from bridges.torproject.org

Reported by: proper Owned by:
Priority: Low Milestone: Tor: unspecified
Component: Circumvention/Pluggable transport Version:
Severity: Normal Keywords: tor-pt tor-bridge usability needs-design
Cc: whonix-devel@…, linda Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Currently bridges.torproject.org returns replies for copy and paste in the following form.

obfs4 ip:port fingerprint

This is easy for copied into tor-launcher. But one who wanted to copy this into its /etc/tor/torrc would have to modify it to.

Bridge obfs4 ip:port fingerprint

This is a usability issue. Therefore, could you make for example /etc/tor/torrc config option obfs4 a shortcut to Bridge obfs4 etc.?

Ideally, pluggable transports once they plugged into Tor using ClientTransportPlugin would be responsible for running the code for setting up these shortcuts themselves so you don't have to maintain a static/outdated list of shortcuts within the Tor core.

Child Tickets

Change History (10)

comment:1 Changed 4 years ago by nickm

Component: TorBridgeDB
Owner: set to isis

comment:2 Changed 4 years ago by yawning

Component: BridgeDBPluggable transport
Keywords: tor-pt lorax added
Milestone: Tor: unspecified
Owner: changed from isis to asn
Priority: normalminor

Err this is a Tor issue. The BridgeDB response format is fine for Tor Browser, so it's not really BridgeDB's problem, and fixing it like the want would require changing the config parsing code. Re-triaging since it's mostly a PT issue.

I'm inclined to say "No", since cluttering up the PT code and config parsing code for this sort of thing isn't my idea of fun, and the naive implementation of this would introduce a ordering requirement between ClientTransportPlugin directives and Bridge lines.

comment:3 Changed 4 years ago by asn

FWIW, #9445 and #9156 are old but related bugs.

comment:4 Changed 4 years ago by asn

It seems to me that it's useful to come up with a bridgedb output that will work both for TBB and torrc.

I agree that we should not complicate stable code further for this though.

comment:5 Changed 4 years ago by yawning

We could add Bridge to the Bridge DB output, but that sucks more for mobile etc. I'm not sure what size QR codes we currently are using/planning on using.

The earliest this will happen is the 0.2.8.x dev cycle anyway, so I'm going to ignore this for the foreseeable future.

comment:6 Changed 4 years ago by isis

See also #5851, which is why BridgeDB removed the "Bridge " prefix and also why TorLauncher added support for bridge lines with or without the "Bridge " prefix.

comment:7 Changed 4 years ago by isis

FWIW, I'm willing to add the "Bridge " prefix back in. I've been avoiding doing so because I though it would confuse users to remove it and then put it back a month later. But now that no one should be using Vidalia, and (sadly) plenty of people still need to edit a torrc file… it seems like it could be helpful to put it back.

comment:8 Changed 2 years ago by nickm

Cc: linda added
Keywords: tor-bridge usability needs-design added; lorax removed
Severity: Normal

comment:9 Changed 6 months ago by teor

Owner: asn deleted
Status: newassigned

asn does not need to own any obfuscation tickets any more. Default owners are trouble.

comment:10 Changed 6 months ago by cohosh

Status: assignednew

tickets were assigned to asn, setting them as unassigned (new) again.

Note: See TracTickets for help on using tickets.