25/11/13 21:15, intrigeri wrote: > Hi, > > anonym wrote (25 Nov 2013 19:24:51 GMT) : >> 21/11/13 09:17, intrigeri wrote: >>> I'm concerned about the impact on our test suite: it seems suboptimal >>> to (automatically) test code paths that are different from the ones >>> most users will go through. > >> Even if we add a comprehensive cucumber feature that tests all scenarios >> we think matter for both cases (i.e. enabled and disabled)? > > This would definitely be better. > > However... when we find ourselves in a position when we can base > implementation decisions on "let's have more automated tests", then > I'm happy, but I don't think it would be wise to act as if we were > there yet.
Indeed. :) >>> IIRC we're setting a kernel cmdline >>> parameter when running the test suite, so perhaps this changing of >>> defaults could be disabled when a testing environment is detected? > >> This would be both easy and appropriate, yes. > >> Another approach is to change the default only for known problematic VMs >> (currently only VirtualBox), which is made easy since virt-what tells us >> which VM it detects. We this we would *by default* spoof the MAC address >> of Tails in the scenario where someone runs Tails in a e.g. >> libvirt/qeumu with a bridged adapter on a hostile network (it's up to >> the user to then also spoof the much more important *real* MAC address >> of the host computer). A small gain, I suppose. > > I agree it's a small gain, compared to the simpler and more robust > (not depending on what specific string virt-what outputs) "don't > change the defaults when a testing environment is detected". True. I implemented the simpler approach in commit 63769ad (Tails Greeter's repo). Cheers! _______________________________________________ tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev
