13/05/14 22:48, intrigeri wrote: > anonym wrote (13 May 2014 15:54:22 GMT) : >>> Regarding the removal of test suite steps that look at notifications: [...] >>> 2. These steps were also useful to... actually test that we're >>> displaying these notifications. In the context of the test suite, >>> they are annoying, but for actual users, they are features. >>> We have dropped tests such as "I see a notification that Unsafe >>> browser is starting" from our manual test suite when the >>> automated test suite implemented it. And now, we're dropping this >>> test from the automated test suite too. I've not carefully >>> checked if other similar tests were removed. That looks like >>> a regression to me. What do you think? > >> ACK. I'll bring it back tomorrow with some needed modifications.
I've brought these checks back in commits bd095dd and 7b6d3d6. You really nailed it this time. :) Running the test suite now uncovered that the start and stop notifications aren't shown for the Unsafe Web Browser. Apparently running `notify-send` as root (as the script does) shows nothing in Wheezy, so I switched to `tails-notify-user`. Hopefully you don't mind that I fixed this in this branch and not a dedicated one. Any way, I'm worried that Wheezy's default notification timeout of 5 seconds (which BTW is not a bug [1]) may end up causing us problems since Sikuli certainly may need more than that to find the image, in particular on slow hardware. We'll see. [1] https://bugzilla.gnome.org/show_bug.cgi?id=665761 > Thank you. I won't be able to test and review this before May 24, so > better nag bertagaz to take care of it (at least of the testing part, > if he doesn't feel comfortable reviewing the thing). His email hasn't been working, so I hope you can have a look. >>> I don't understand the complexity added by commit bc6805ec, and the >>> commit message tells me nothing about it. Have you seen actual cases >>> when TailsData was *not* unlocked+mounted, after t-p-s exited? > >> That step is also used in scenarios when t-p-s isn't run at all, and >> persistence is disabled, see e.g. "Booting Tails from a USB drive with a >> disabled persistent partition". > > OK... but I still don't get why some action is needed on Wheezy, or > rather, I don't get why no action was needed on Squeeze, given what > I've reported on #7056. cryptsetup changed [1] what it does when you try to luksOpen an already unlocked device in version 1.2. With Squeeze's 1.1.2 we got away with just: @vm.execute("echo #{pwd} | cryptsetup luksOpen #{dev} #{name}") luks_dev = "/dev/mapper/#{name}" even if the device was already open... but that resulted in *an additional* dm mapping being created! You can even mount both mappings, but the two do not seem to sync when you write to one of them, so it looks like a really bad thing to allow. So, since we have 1.4.3 in Wheezy we cannot do this any more, and we need to find (potential) old mappings and use them instead. I admit I didn't do all this homework before now -- earlier I just went with the error message ("Cannot use device ... (already mapped or mounted)") and couldn't see any other way around this. Still, I agree the for-loop seems unnecessarily complex but I couldn't find any convenient way to query udisks for existing LUKS mappings from a particular device. [1] https://code.google.com/p/cryptsetup/source/detail?r=b7caa72acdd1d66cfabe5358392be330276099fb Cheers! _______________________________________________ Tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
