29/11/13 12:31, intrigeri wrote:
> (I'm acting with my RM hat for the next two Tails releases on.)
>
> It's now clear feature/spoof-mac won't make it into 0.22. No big deal,
> as long as it's merged soon enough and we can publish some beta
> version of it by the end of the year.
I think we're actually *pretty* close to this being possible at the moment.
> I'd like to have some visibility on what's left to do for this to
> happen.
>
> I've updated the existing tickets to match the current state.
>
> anonym, I think now would be a great time to sum up what the current
> state is:
>
> * remaining coding blockers
Most coding is done. See in particular commit 7ead3ed for the fail-safe
(as an early Christmas gift for you, I gettext:ised it (commit 6c6604a)
even before you asked for it :)))), which I pushed in a hurry without
any mention a few days ago. There's also a new TG in the APT suite, and
both the feature branch and the APT suite were merged into experimental.
Feel free to test it; to force an error that triggers the fail-safe I
boot with rootpw=whatever on the kernel cmdline and do something like
the following before login in with TG:
--- a/config/chroot_local-includes/usr/local/sbin/tails-spoof-mac
+++ b/config/chroot_local-includes/usr/local/sbin/tails-spoof-mac
@@ -55,6 +55,8 @@ set_log_tag spoof-mac
NIC=${1}
+[ "${NIC}" = wlan0 ] && exit 0
+
if ! mac_spoof_is_enabled; then
exit 0
fi
How to properly simulate hardware with an issue like this (either for
manual testing or the automated test suite) will be interesting. That
is, if we can do anything better than the above...
Two things that remain comes to mind (although I promise to scan this
thread for more loose ends):
* Perhaps checking the return status of tails-unblock-network in TG's
post-login script? If it fails due to `set -e`, NM may not start,
leaving the user without networking. Yet another notification?
* Investigate the NM passive probe fingerprinting issue. This is not
strictly coding, but it very well may turn into coding, which scares
me a bit since you in an earlier email thought it had to be
"addressed in the first released iteration of this work". IMHO, let's
at least not require that for the beta, so we can get it out there
faster just to see if in particular the network blocking and
unblocking isn't causing large-scale disasters. And the by-default
enabled MAC spoofing, of course...
Oh, and another (good?) thing. MAC spoofing suddenly isn't causing
issues in Virtualbox again. WTF? This I'm utterly perplexed about.
> * remaining design documentation blockers (the blueprint didn't
> make it into a design doc yet, right?)
Not yet, no.
> * remaining user documentation blockers (are there placeholders doc
> pages with indications for doc writers already?)
I'll cook something up. At the moment there are only hints in the design
doc, plus the rather comprehensive "use cases" section which has to be
distilled into something manageable and user-friendly by our creative
doc writers
> * once all coding blockers are solved, I think a bolder call for
> testing (pointing to a nightly built ISO from experimental) would
> be good: some of us told that they are lost in this huge thread,
> and it's unclear to them how close we are to the "please widely
> test this code" state (I know, one call for testing was sent as
> part of this thread, but I wouldn't expect everyone to have read
> the whole thread and seen it, so a dedicated email in a new thread
> could be worth it)
Right.
> I'd love to see tickets created for all the blockers, so that one can
> easily track the progress of this feature.
Definitely. I'll return to this post in a few days (when I have more
time on my hands) with more affirmative answers + proper bugs/tasks. See
this post more as a heads up.
Cheers!
