Author: anonym Date: To: The Tails public development discussion list Subject: Re: [Tails-dev] [RFC] Design (and prototype) for MAC spoofing in
Tails
21/11/13 09:10, intrigeri wrote: > Hi,
>
> anonym wrote (21 Nov 2013 05:58:37 GMT) :
>> 04/11/13 14:49, intrigeri wrote:
>>> To end with, I notice the blueprint was not updated (modulo typos etc.
>>> I fixed) since almost a month. At some point, you'll want to make it
>>> include all the good thinking that was put into the
>>> recent discussions.
>
>> Done.
>
> Great work, congrats! This blueprint will become a wonderful design
> document, that we can hand out to anyone wanting to audit this
> feature. I've pushed a few typo fixes and minor rephrasing (316f2fc).
Thanks! Sorry for forgetting to M-x ispell.
> Remarks:
>
> * The "plugging" and "plugged" (of network interfaces) words are used
> in multiple places in a way that's not obvious without knowing the
> implementation details (or reading the relevant section below).
Done (f8bb474).
> * When pointing to scripts and configuration files, please use the
> tails_gitweb shortcut so that Luke^Wanyone can simply click on
> a link to read the source.
Done (1821cf7).
> * I had to re-read this sentence a few times to understand what it
> meant: "Therefore we make an exception to have the MAC spoofing
> option enabled by default in Tails Greeter if it detects that Tails
> is running inside a virtual machine" => please rephrase.
What do you think about commit c177710?
> * Regarding "It would obviously require to drop `set -e`, because
> errors are indeed what could cause this to happen." --> err, well,
> I kinda disagree that letting errors propagate further, just so we
> can enjoy detecting it later, is "obvious". "set -e" detects a given
> class of error conditions, great. The proposed failsafe check would
> detect another (probably overlapping) class of error conditions.
> I think that both should coexist.
My point is that `set -e` doesn't simply "detect" errors, like you put
it; it *terminates* the script upon certain error conditions, which
most likely prevents whatever failsafe we have from detecting its class
of errors (at least the non-overlapping part) and warn the user etc. Or
am I misunderstanding how you want this failsafe to be implemented?
> * Regarding "Loss of hotplugged devices" --> I'll do the test.
Excellent! I'm glad it looks like this is not a problem.
