Bug #10926
The I2P AppArmor confinement test case succeeds even when I2P is not confined
100%
Description
During the 2.0~rc1 test suite run, “Scenario: I2P’s AppArmor profile is in enforce mode” apparently passed, while it should have noticed that on current Tails/Jessie, I2P is not confined (Bug #10925).
I’m assuming that this test was verified to actually work when it was first implemented and merged (commit:a033ba69, commit:c2c96e76), and that this is a regression on Jessie, hence the parent task + assignee I’m setting.
Subtasks
History
#1 Updated by intrigeri 2016-01-13 14:25:33
- Subject changed from The I2P AppArmor confinement test case wrongly succeeds to The I2P AppArmor confinement test case succeeds even when I2P is not confined
#2 Updated by anonym 2016-01-21 22:46:25
- Status changed from Confirmed to In Progress
Applied in changeset commit:c2eeb5b4ee74351d4a9756ee21c3d93562672445.
#3 Updated by anonym 2016-01-21 22:47:04
- Assignee changed from anonym to kytv
- % Done changed from 0 to 50
- QA Check set to Ready for QA
- Feature Branch set to test/10926-fix-apparmor-check
By looking at the ‘the running process "(.+)" is confined with AppArmor in (complain|enforce) mode’ step I can immediately tell that it’s incorrect:
assert(mode, get_apparmor_status(pid))
where mode is a String, so assert (which only triggers on false or nil) always passes. Obviously we want assert_equal… :)
So, yeah, anti-tests and all that.
#4 Updated by anonym 2016-01-22 15:27:16
- Status changed from In Progress to Fix committed
- % Done changed from 50 to 100
Applied in changeset commit:c7d0843f044be4b74f779a97dc956cb39c2ab82a.
#5 Updated by anonym 2016-01-22 15:28:30
- Assignee deleted (
kytv) - QA Check changed from Ready for QA to Pass
The overhead of our review’n’merge process just seems ridiculous in this case. I just went a head and merged this myself.
#6 Updated by anonym 2016-01-27 13:31:35
- Status changed from Fix committed to Resolved