Opened 7 years ago

Closed 7 years ago

#5551 closed project (implemented)

Deployed obfsproxy package for both bridge and user side

Reported by: karsten Owned by: Sebastian
Priority: Medium Milestone:
Component: Applications/Tor bundles/installation Version:
Severity: Keywords: SponsorF20121101
Cc: nickm, asn, erinn, Sebastian Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Item 11 from org/sponsors/SponsorF/Year2 is: "obfsproxy: get a deployed package for both bridge and user side."

AFAICS, we have bundles for the user side, but we're currently not maintaining them. When do we think we'll maintain them again? And is it reasonable to call the first half of this deliverable done once we're maintaining them again, even without finishing Vidalia/BridgeDB/statistics/NAT punching support as written in the pluggable transport deployment roadmap?

Looks like we don't have bundles for the bridge side yet. The pluggable transport deployment roadmap says that "we plan to incorporate obfsproxy in Tor Bridge Bundle." When do we plan to do that? And can we call the second half of this deliverable done once we have a Tor Bridge Bundle with obfsproxy, even without Vidalia/BridgeDB/statistics/NAT punching support?

Cc'ing the people who come to mind when thinking about obfsproxy and bundles. Optimistically assigning to July. Who's going to lead this deliverable?

Child Tickets

TicketStatusOwnerSummaryComponent
#5613closedSebastianMake obfsproxy package for bridge sideApplications/Tor bundles/installation

Change History (10)

comment:1 Changed 7 years ago by karsten

Owner: erinn deleted
Status: newassigned

Undoing Trac's highly annoying auto-assignment.

comment:2 Changed 7 years ago by Sebastian

I've started working on a script to make the obfsproxy bundles a couple of days ago. Once that works on all platforms, the next step is for Erinn to integrate it into the current builders, and we'll have that done.

comment:3 in reply to:  description ; Changed 7 years ago by arma

Replying to karsten:

AFAICS, we have bundles for the user side, but we're currently not maintaining them. When do we think we'll maintain them again?

Sounds like we should open a child ticket for this one.

And is it reasonable to call the first half of this deliverable done once we're maintaining them again, even without finishing Vidalia/BridgeDB/statistics/NAT punching support as written in the pluggable transport deployment roadmap?

I think so -- once we are consistently making Tor Browser Bundles with Obfsproxy built-in, and some hard-coded obfsproxy bridges that come configured by default, I would call this one done.

But that said, why do you say 'vidalia' above? The TOBB we made for Iran had Vidalia and you could use that Vidalia to configure your Tor to use new obfsproxy bridges.

Looks like we don't have bundles for the bridge side yet. The pluggable transport deployment roadmap says that "we plan to incorporate obfsproxy in Tor Bridge Bundle." When do we plan to do that?

Sounds like another good child ticket.

And can we call the second half of this deliverable done once we have a Tor Bridge Bundle with obfsproxy, even without Vidalia/BridgeDB/statistics/NAT punching support?

The normal Tor Bridge Bundles come with Vidalia, yes? These ones should too.

But I think there's no reason to make Obfsproxy have more features before we can call this ticket done.

comment:4 in reply to:  3 Changed 7 years ago by karsten

Replying to arma:

Replying to karsten:

AFAICS, we have bundles for the user side, but we're currently not maintaining them. When do we think we'll maintain them again?

Sounds like we should open a child ticket for this one.

Looks like in the meantime Sebastian has uploaded new bundles and is planning to maintain them in the future. No child ticket needed anymore.

And is it reasonable to call the first half of this deliverable done once we're maintaining them again, even without finishing Vidalia/BridgeDB/statistics/NAT punching support as written in the pluggable transport deployment roadmap?

I think so -- once we are consistently making Tor Browser Bundles with Obfsproxy built-in, and some hard-coded obfsproxy bridges that come configured by default, I would call this one done.

Okay.

But that said, why do you say 'vidalia' above? The TOBB we made for Iran had Vidalia and you could use that Vidalia to configure your Tor to use new obfsproxy bridges.

Right, the Vidalia part is already done on user side.

Looks like we don't have bundles for the bridge side yet. The pluggable transport deployment roadmap says that "we plan to incorporate obfsproxy in Tor Bridge Bundle." When do we plan to do that?

Sounds like another good child ticket.

Created #5613.

And can we call the second half of this deliverable done once we have a Tor Bridge Bundle with obfsproxy, even without Vidalia/BridgeDB/statistics/NAT punching support?

The normal Tor Bridge Bundles come with Vidalia, yes? These ones should too.

Ah, I didn't mean to exclude Vidalia. I meant extending Vidalia to be better integrated with obfsproxy.

But I think there's no reason to make Obfsproxy have more features before we can call this ticket done.

Okay.

comment:5 Changed 7 years ago by karsten

Owner: set to Sebastian

Erinn and Sebastian agreed that Sebastian is going to lead this deliverable. Assigning the ticket to him.

Now we need a schedule with substeps and dates, so that "make bundles" is no longer an atomic multi-day (or multi-week?) action anymore.

comment:6 Changed 7 years ago by karsten

Here are some more notes from the #tor-dev meeting on April 12, which are partially contained in my two earlier comments, but not as cleanly written:

  • Deliverable 11 consists of two parts: obfsproxy packages for users and for bridge operators. Sebastian made new obfsproxy packages for users (with hard-coded obfsproxy bridge addresses) and uploaded them on April 12. That means that the first half of 11 is done.
  • For the bridge side of obfsproxy Sebastian, George, and Roger agreed that the deliverable ends when we stick obfsproxy into the bridge bundle and make it spawn an obfuscated bridge, even though the user will have to get her address in a not-very-nice way (from the "message log"). There's now a new child ticket #5613 for this part of the deliverable.
  • Once the sponsor F deliverable is done, we'll work on improving bridge bundles as a sponsor Z deliverable (#5612). Improvements include: export transport information in the control port and have Vidalia display that nicely to the user (#5609); make BridgeDB distribute obfsproxy addresses. We have a pluggable transport deployment roadmap that tells us what's left to do in the sponsor Z deliverable.

Substeps and dates are under way. Sebastian suggested a schedule that's pending Erinn's confirmation because it requires her to teach Sebastian about the current Vidalia Bridge Bundle build setup.

comment:7 Changed 7 years ago by karsten

Sebastian and I came up with this schedule after getting some valuable input from Erinn:

  1. May 8: Learn how bridge bundles get built currently, where scripts are, etc.
  2. May 22: Make a proof-of-concept bundle that can get testing.
  3. June 22: Adapt the stuff from step 1 to handle building these things automatically.

comment:8 Changed 7 years ago by karsten

Milestone: Sponsor F: July 1, 2012Sponsor F: November 1, 2012

July 1 has passed, so moving this ticket to November 1.

comment:9 Changed 7 years ago by karsten

Keywords: SponsorF20121101 added
Milestone: Sponsor F: November 1, 2012

Switching from using milestones to keywords for sponsor deliverables. See #6365 for details.

comment:10 Changed 7 years ago by karsten

Resolution: implemented
Status: assignedclosed

We have client and bridge side bundles. Closing this ticket and summarizing the deliverable as follows: "We have client side bundles containing the 0.2.3.x release series and bridge side bundles for Windows containing the 0.2.4.x release series."

Note: See TracTickets for help on using tickets.