Opened 7 years ago

Closed 4 years ago

#5418 closed task (fixed)

Review and deploy code so that BridgeDB can give out unblocked bridges

Reported by: runa Owned by: isis
Priority: Medium Milestone:
Component: Circumvention/BridgeDB Version:
Severity: Keywords: bridgedb-database, reachability, bridgedb-0.3.2
Cc: isis Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

In #5027, Aaron wrote code for BridgeDB to dynamically produce rings of bridges 'Not blocked in' a specified country. Bridges are not mapped to a specific country or region, but BridgeDB's response will contain only unblocked bridges (if available).

The next step is to review and deploy this code on to bridges-test.tpo.

Child Tickets

TicketStatusOwnerSummaryComponent
#5949closedaagbsnBridgeDB reachability/blocking should be per address:portCircumvention/BridgeDB

Change History (3)

comment:1 Changed 6 years ago by isis

Cc: isis added
Keywords: bridgedb-database reachability difficult added
Owner: changed from aagbsn to isis
Status: newassigned

This code will need some love. In particular, we will likely want a new database which stores:

  1. The ip:port pair which is "blocked"
  2. What country the block is seen in.
  3. When the block was first discovered/reported in that country.
  4. The method used to discover the blocking
  5. The method used to verify the block, or additional confirmations (if using some sort of remote reporting mechanism).
  6. When the latest block verification/confirmation took place.

This will therefore need to be on an "ip:port + country" basis. And, because this requires another database (or additional tables in the current one; but I'd prefer them to be kept separate), the code in bridgedb.Bridges which aagbsn wrote will need some love. Also, if I recall correctly, there were some old-style Python classes in there which will trigger some rather severe and annoying Python 2.x bugs.

comment:2 Changed 6 years ago by isis

Status: assignedneeds_revision

comment:3 Changed 4 years ago by isis

Keywords: bridgedb-0.3.2 added; difficult removed
Resolution: fixed
Status: needs_revisionclosed

I've rewritten large sections of the code for setting a bridge as being blocked, or its transports, or some of its transports, or some ports, or some addresses, and any combination of any of that. This code is in the new bridgedb.bridges.Bridge class that was introduced for #9380.

I've decided for #12505 to remove all the remnant code from #5027. It needed to be entirely refactored. The database table which was set up for the code hasn't ever been used, so I'm ripping the whole thing out.

The last pieces that we'll need are:

  • (#12031) A way to store info for blocked bridges in the new databases. This should be quite simple given the new data structures and the methods exposed by the new bridgedb.bridges.Bridge class.
Note: See TracTickets for help on using tickets.