Add pluggable-transport support to Chutney

We need to make PTs in general, and Snowflake in particular, more reliable and well-tested. On way to do that is with realistic integration tests, using Chutney.

changed milestone to %Tor: 0.4.2.x-final

Trac:
Parent Ticket: #29267 (moved)
Child Ticket(s): #30459 (moved)

added 041-accepted-20190115 041-deferred-20190530 actualpoints::1 component::core tor/chutney milestone::Tor: 0.4.2.x-final network-team-roadmap-2019-Q1Q2 owner::nickm parent::29267 points::2 priority::medium resolution::fixed reviewer::nickm reviewer::teor severity::normal sponsor::19 status::closed tor-ci tor-pt type::task labels

Trac:
Keywords: N/A deleted, tor-pt added

Let's review these tickets at the next meeting using our 041-proposed process. They're on the roadmap, so the review should focus on ticket size and team capacity (and sponsor expectations).

Trac:
Keywords: N/A deleted, 041-proposed-on-roadmap added

Trac:
Points: N/A to 2

I am interested in doing this ticket in February, or if I take a break from PrivCount in January. I can also work with someone else to make it happen. (Or review their changes.)

This PT ticket is on the roadmap, we accepted its points estimate in the meeting without discussion.

Trac:
Keywords: 041-proposed-on-roadmap deleted, 041-accepted-20190115 added

I put together some very fast and simple integration tests for Snowflake specifically, just to be able to quickly check whether or not our changes to snowflake break anything that will show up in the logs: https://github.com/cohosh/snowbox/commit/c05b1d8eefac3f8acb7a87413cf7d7364d6ab5cb

This was written to run in the Docker-based snowflake test environment, which could potentially be used for CI (and would work quite well with gitlab if we more the repo there).

It's very simple right now: it runs each piece of Snowflake in a docker container and greps the logs for common error messages. Pull requests, advice, or examples of similar tests done for little-t-tor are welcome :)

Trac:
Cc: teor to teor, cohosh

These chutney tickets are on the network team roadmap, or they are required for tickets that are on the network team roadmap.

Trac:
Keywords: N/A deleted, network-team-roadmap-2019-Q1Q2 added

Trac:
Cc: teor, cohosh to teor, cohosh, phw

Status: I have chutney testing obfs2 via obfs4proxy in a branch called chutney-obfs4.

This is not yet ready for primetime. For example, it cannot test stuff like obfs4 that requires that the bridge be launched before the client is configured, since chutney currently wants to write every torrc before it starts up every tor.

My branch chutney-obfs4 now supports obfs4 as well. PR at https://github.com/torproject/chutney/pull/29 .

There will be some followup work here to improve test-network.sh, to document all of this better, and to support more PTs, and to make it work with #30459 (moved).

To start this network yourself, run these:

# configure and launch everything except the bridge client
CHUTNEY_CONFIG_PHASE=1 ./chutney configure networks/bridges-obfs4
CHUTNEY_LAUNCH_PHASE=1 ./chutney start networks/bridges-obfs4
# wait a moment for the PT to launch
sleep 2
# configure and launch the bridge client.  
CHUTNEY_CONFIG_PHASE=2 ./chutney configure networks/bridges-obfs4
CHUTNEY_LAUNCH_PHASE=2 ./chutney start networks/bridges-obfs4

As noted above, this happens in two phases because the bridge line can't be constructed until the bridge and its PT are running.

Trac:
Status: new to needs_review
Actualpoints: N/A to 1

Trac:
Owner: N/A to nickm
Status: needs_review to accepted

Trac:
Status: accepted to needs_review

Trac:
Keywords: N/A deleted, tor-ci added

Marking these tickets as deferred from 041.

Trac:
Keywords: N/A deleted, 041-deferred-20190530 added

Trac:
Milestone: Tor: 0.4.1.x-final to Tor: 0.4.2.x-final

Replying to nickm:

My branch chutney-obfs4 now supports obfs4 as well. PR at https://github.com/torproject/chutney/pull/29 .

Looks good to me, I had a few minor comments and questions. I haven't run it yet.

There will be some followup work here to improve test-network.sh, to document all of this better, and to support more PTs, and to make it work with #30459 (moved).

Did you want to make those changes in this ticket, or open another ticket?

To start this network yourself, run these: {{{

configure and launch everything except the bridge client

CHUTNEY_CONFIG_PHASE=1 ./chutney configure networks/bridges-obfs4 CHUTNEY_LAUNCH_PHASE=1 ./chutney start networks/bridges-obfs4

wait a moment for the PT to launch

sleep 2

configure and launch the bridge client.

CHUTNEY_CONFIG_PHASE=2 ./chutney configure networks/bridges-obfs4 CHUTNEY_LAUNCH_PHASE=2 ./chutney start networks/bridges-obfs4 }}}

As noted above, this happens in two phases because the bridge line can't be constructed until the bridge and its PT are running.

I wonder if we could expose a better interface to two-phase launches. I guess we can do that in test-network.sh.

Trac:
Status: needs_review to needs_revision

Replying to teor:

Replying to nickm: [...]

There will be some followup work here to improve test-network.sh, to document all of this better, and to support more PTs, and to make it work with #30459 (moved).

Did you want to make those changes in this ticket, or open another ticket?

Let's open new tickets for those.

Replying to teor:

Replying to nickm:

My branch chutney-obfs4 now supports obfs4 as well. PR at https://github.com/torproject/chutney/pull/29 .

Looks good to me, I had a few minor comments and questions. I haven't run it yet.

I only saw one comment on the branch; I made a corresponding change, but I don't know if I missed something?

Trac:
Status: needs_revision to needs_review

Replying to nickm:

Replying to teor:

Replying to nickm:

My branch chutney-obfs4 now supports obfs4 as well. PR at https://github.com/torproject/chutney/pull/29 .

Looks good to me, I had a few minor comments and questions. I haven't run it yet.

I only saw one comment on the branch; I made a corresponding change, but I don't know if I missed something?

I don't think so, I think I wrote the rest of my comments in this ticket.

I didn't notice until now, but this change breaks both bridge jobs in the chutney CI: https://travis-ci.org/torproject/chutney/builds/543863234

I'd like to make sure there is CI for these pluggable transports, I think the best way to do that is adding them to the bridge jobs. I'll try to do that later today.

There will be some followup work here to improve test-network.sh, to document all of this better, and to support more PTs, and to make it work with #30459 (moved).

Once we get pluggable transports into test-network.sh, let's think about how to test pluggable transports in Tor's CI, or in the PT CIs.

I've made a change to fix that formatting error; should be pretty simple. Let's see if there are any other errors.

The CI failed because 0.3.4 no longer exists, and the tests fail on 0.2.9 (which is installed when 0.3.4 is not available). We have an open ticket to remove 0.3.4 from chutney's CI.

I expect CI to fail on obsolete Tor versions due to #30826 (moved).

I opened #30884 (moved), #30885 (moved), and #30886 (moved) for follow up.

Trac:
Reviewer: N/A to teor

Trac:
Parent: N/A to #29267 (moved)

Now that we have follow-up tickets, this is ready for merge. (It doesn't break existing CI, which is good enough for an initial merge.)

Trac:
Status: needs_review to merge_ready

Hi Nick,

I squashed your pull request at: https://github.com/torproject/chutney/pull/34

There were a few conflicts around extra = "" and extra = '', I think I resolved them correctly, but please check I didn't mangle anything, and put this ticket back in merge_ready.

The CI will test a merge to the latest master with #30876 (moved) and #29263 (moved). I expect that it will pass, but I want to make sure we don't have any issues with the new PT code.

Trac:
Status: merge_ready to needs_review
Reviewer: teor to teor, nickm

Hmm, yes, the fixups were on the wrong commits, and I did mangle things slightly. I edited the branch, and force-pushed.

I also added a commit with a minor refactor, and added some comments.

Should we add documentation in the README? Or do you want to wait until we add PTs as a feature in test-network.sh?

This looks fine to me (based on review of git diff chutney-obfs4 tor-github/pr/34).

Should we add documentation in the README? Or do you want to wait until we add PTs as a feature in test-network.sh?

I'm fine with either approach, with a slight preference for the latter.

Trac:
Status: needs_review to merge_ready

Replying to nickm:

This looks fine to me (based on review of git diff chutney-obfs4 tor-github/pr/34).

Should we add documentation in the README? Or do you want to wait until we add PTs as a feature in test-network.sh?

I'm fine with either approach, with a slight preference for the latter.

I want to change all the README examples to use test-network.sh in #30720 (moved), so there's not much point adding another raw chutney command example.

Merged to master as 0a83ecf.

I opened #30884 (moved), #30885 (moved), and #30886 (moved) for follow up.

Trac:
Resolution: N/A to fixed
Status: merge_ready to closed

closed

changed time estimate to 16h

added 8h of time spent

mentioned in issue #29267 (moved)

mentioned in issue #29280 (moved)

mentioned in issue #29729 (moved)

mentioned in issue #29956 (moved)

mentioned in issue #30884 (moved)

mentioned in issue #30885 (moved)

mentioned in issue #30886 (moved)

mentioned in issue #30928 (moved)

mentioned in issue #30459 (moved)

moved to tpo/core/chutney#29024 (closed)

mentioned in issue tpo/core/chutney#30884

mentioned in issue tpo/core/tor#30885

mentioned in issue tpo/anti-censorship/trac#29267 (closed)