Feature #6305
Write tests for Tor bridges
100%
Description
Write tests to ensure that the bridge functionnality is well supported in Tails.
Subtasks
History
#1 Updated by intrigeri 2013-09-26 06:12:03
- Target version set to Sustainability_M1
#2 Updated by intrigeri 2013-10-03 06:12:16
- Subject changed from Write bridges tests to Write tests for Tor bridges
#3 Updated by intrigeri 2014-03-04 23:36:57
- Parent task changed from
Feature #6298toFeature #6839
#4 Updated by intrigeri 2014-08-26 23:12:04
- related to deleted (
)Feature #6298: Write more automated tests
#5 Updated by intrigeri 2014-08-26 23:14:13
- related to
Feature #7821: Automatic tests for Tor added
#6 Updated by intrigeri 2014-08-26 23:14:28
- Assignee set to anonym
- Target version changed from Sustainability_M1 to Tails_1.2.2
#7 Updated by sajolida 2014-10-14 15:45:31
- blocked by #8117 added
#8 Updated by sajolida 2014-10-14 15:47:31
- blocks deleted (
#8117)
#9 Updated by sajolida 2014-10-14 15:47:36
- blocks #8117 added
#10 Updated by anonym 2014-10-28 23:35:13
- Status changed from Confirmed to In Progress
- % Done changed from 0 to 30
- Feature Branch set to test/6305-tor-bridges
Did some minimal work on this today, which actually may be enough:
- While it only tests obfs3 bridges, I think that’s enough (until we support scramblesuit, i.e.
Feature #7909), since “vanilla” and obfs2 bridges are obsolete. Adding scenarios for them would be little more than a trivial copy-paste away, but IMHO that’d only make the test suite run slower.
- Also, in the manual test suite’s bridge section we have the vague “Use the Internet” step, to generate some network activity. The current tests only activity is the actual Tor bootstrap and the upgrade check. If that isn’t enough I suppose can, quite arbitrarily, throw in a “check that Tails’ website loads in the Tor Browser” step too.
#11 Updated by intrigeri 2014-12-06 18:34:10
anonym wrote:
> Did some minimal work on this today, which actually may be enough:
Congrats!
> * While it only tests obfs3 bridges, I think that’s enough (until we support scramblesuit, i.e. Feature #7909), since “vanilla” and obfs2 bridges are obsolete. Adding scenarios for them would be little more than a trivial copy-paste away, but IMHO that’d only make the test suite run slower.
I don’t see regular bridges as obsolete (people for whom they work should not consume resources from the smaller PT bridge pools IMO), and I see value in testing both bridges that are handled by Tor itself in addition to bridges that are managed by PTs.
> * Also, in the manual test suite’s bridge section we have the vague “Use the Internet” step, to generate some network activity. The current tests only activity is the actual Tor bootstrap and the upgrade check.
Good enough.
#12 Updated by anonym 2014-12-12 16:41:52
- Target version changed from Tails_1.2.2 to Tails_1.2.3
#13 Updated by anonym 2015-01-13 14:14:32
- Target version changed from Tails_1.2.3 to Tails_1.3
#14 Updated by Tails 2015-02-19 20:48:32
Applied in changeset commit:2c420ac45ea9a92d4fec5b81071adbfbcc14d539.
#15 Updated by anonym 2015-02-19 20:53:02
- related to deleted (
)Feature #7821: Automatic tests for Tor
#16 Updated by anonym 2015-02-19 20:53:05
- blocked by
Feature #7821: Automatic tests for Tor added
#17 Updated by anonym 2015-02-19 20:55:51
- Assignee changed from anonym to kytv
- % Done changed from 30 to 50
- QA Check set to Ready for QA
Forced pushed a completely re-worked version of the branch. It’s based on test/7821-tor
, which isn’t merged as of writing this, so I added a blocker to Feature #7821. I’d still appreciate an initial code review even before test/7821-tor
is merged, is convenient.
#18 Updated by anonym 2015-02-19 21:42:00
anonym wrote:
> I’d still appreciate an initial code review even before test/7821-tor
is merged, is convenient.
Tip for this:
git log --cc --reverse -p origin/testing..origin/test/6305-tor-bridges ^origin/test/7821-tor
#19 Updated by kytv 2015-02-20 02:52:41
Initial comments:
One problem, so far, perhaps with wiki/src/contribute/release_process/test/usage.mdwn
or features/step_definitions/tor.rb
.
Running the time_syncing.feature
failed with
Scenario: Clock with host's time in bridge mode # features/time_syncing.feature:54
When the network is plugged # features/step_definitions/common_steps.rb:112
And the Tor Launcher autostarts # features/step_definitions/tor.rb:322
And I configure some Bridge pluggable transports in Tor Launcher # features/step_definitions/tor.rb:327
uninitialized constant AssertionFailedError (NameError)
./features/step_definitions/tor.rb:335:in `rescue in block in <top (required)>'
./features/step_definitions/tor.rb:331:in `/^I configure some (\w+) pluggable transports in Tor Launcher$/'
features/time_syncing.feature:57:in `And I configure some Bridge pluggable transports in Tor Launcher'
And Tor is ready # features/step_definitions/common_steps.rb:306
Then Tails clock is less than 5 minutes incorrect # features/step_definitions/time_syncing.rb:35
My features/config/local.yml
contained lines like
Tor:
Transports:
bridge:
- ipv4_address: "xxx.yyy.zzz.aaa"
ipv4_port: xxxx
fingerprint: "SOMEFINGERPRINT"
extra:
.....
and wiki/src/contribute/release_process/test/usage.mdwn
contains
where the type `$TYPE` (and `$ANOTHER_TYPE`) should be something like
`obfs4` or `bridge` (the first type) or whatever Tor calls them. ...
When I changed the yml file to contain Bridge
the test proceeded.
To be continued…
#20 Updated by kytv 2015-02-20 16:20:49
- Assignee changed from kytv to anonym
- QA Check changed from Ready for QA to Dev Needed
The only problem that I saw was with respect to the config file handling (and maybe the documentation).
If we want to mandate that the bridge_type
is upcase!
’d and the config file specifies obfs3
I should see the warning
It seems no '#{bridge_type}' pluggable transports are defined in your local configuration file
but instead I saw
uninitialized constant AssertionFailedError (NameError)
When bridge_type
is in the correct format in the yaml file the tests—AFAICT—test what should be tested.
If bridge_type
should be specified with a leading capital letter:
diff --git a/wiki/src/contribute/release_process/test/usage.mdwn b/wiki/src/contribute/release_process/test/usage.mdwn
index 813d677..9376cee 100644
--- a/wiki/src/contribute/release_process/test/usage.mdwn
+++ b/wiki/src/contribute/release_process/test/usage.mdwn
@@ -103,12 +103,12 @@ The format is:
[...]
where the type `$TYPE` (and `$ANOTHER_TYPE`) should be something like
-`obfs4` or `bridge` (the first type) or whatever Tor calls them. Both
+`Obfs4` or `Bridge` (the first type) or whatever Tor calls them. Both
`fingerprint` and `extra` are optional and can be left empty (or
-skipped completely), but e.g. `extra` is necessary for `obfs4` type
+skipped completely), but e.g. `extra` is necessary for `Obfs4` type
bridges, for the `cert=... iat-mode=...` stuff, and the same for
-`scramblesuite`'s `password=...`.
+`Scramblesuite`'s `password=...`.
This setting is required for `tor_bridges.feature` (requires types
-`bridge`, `obfs2`, `obfs3` and `obfs4`) and `time_syncing.feature`
-(requires type `bridge` only).
+`Bridge`, `Obfs2`, `Obfs3` and `Obfs4`) and `time_syncing.feature`
+(requires type `Bridge` only).
I’m not sure that’s desired but I can see how it’d make sense to have the scalars capitalized!
with the sequences downcased!
.
#21 Updated by anonym 2015-02-22 12:08:17
- Assignee changed from anonym to kytv
- QA Check changed from Dev Needed to Ready for QA
kytv wrote:
> @uninitialized constant AssertionFailedError (NameError)|
Oops, now fixed.
> If bridge_type
should be specified with a leading capital letter:
>
> […]
Thanks for the patch! Now applied.
#22 Updated by intrigeri 2015-02-22 14:22:48
Code review passes. Not tested.
#23 Updated by Tails 2015-02-22 22:42:52
- Status changed from In Progress to Fix committed
- % Done changed from 50 to 100
Applied in changeset commit:4bb35fc063a9fe695a3da7df1062b11d9fc50157.
#24 Updated by intrigeri 2015-02-22 22:43:38
- Assignee deleted (
kytv) - QA Check changed from Ready for QA to Pass
#25 Updated by BitingBird 2015-02-24 22:51:19
- Status changed from Fix committed to Resolved