hi,
anonym wrote (02 Nov 2012 16:42:31 GMT) :
> I'd like to start by saying that I think the work bertagaz did on
> the jruby + sikuli + cucumber combo is really great. He called it
> PoC, but after having worked on it for some time now I say it's
> definitely fit for the task at hand.
Great!
> Next I'd like to announce that the automated test suite, in its
> current unfinished state, actually has found its very first Tails
> bug. [...] In other words, our firewall leaks link-local IPv6
> broadcasts even though it should block everything IPv6 (right?).
Ouch.
WAN hat on: please report it (ticket + email) separately so that it
does not get lost in the middle of this "report on the automated test
suite" thread.
For this reason, I'll refrain from replying here.
> This is promising (not that Tails has this particular bug, but that
> the test suite found it)!
Clearly!
> The framework currently has the following test primitives and other
> interesting features so far: [...]
Awesome.
> I'd like to present the last two with a bit more depth and hear your
> opinions, especially w.r.t. the fact that they alter Tails or "cheat" in
> the testing process, so I wonder how "ethical" they are in the context
> of test-driven development.
> Running arbitrary commands inside the guest VM
> ==============================================
> This is very valuable as it makes many tests that would be truly
> awkward to do with sikuli into something trivial. libvirt doesn't
> seem to have something like VirtualBox' `vboxmanage guestcontrol
> execute` (provided by the VirtualBox guest additions), so
> I implemented a simple remote shell (read: a backdoor (listening on
> port 1337 + firewall exception) so expect havoc on the Tails forum!)
> that starts on the guest when the boot parameter
> "autotest_never_use_me" is present on the kernel cmdline.
"autotest_never_use_me" looks to me like "(speaking to) autotest:
never use me". What about "backdoor_for_autotest"?
> If it's not there, the script that implements the remote shell
> server is removed from the filesystem. Of course, it is still
> accessible from the read-only fs, but it will refuse to start if the
> boot parameter isn't present. My hope is that all these failsafes
> will make sense to all but our most "conspiranoid" users. :)
Looks good.
> Saving/restoring VM snapshots
> =============================
> [...]
For both features, to reply on the 'how "ethical" they are in the
context of test-driven development' topic, I'd need a concrete example
of how this would be used in practice.
Cheers!
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
