[Tails-dev] Tails contributors meeting: Wednesday, March 5
Hi, The next public Tails developers meeting is scheduled for Wednesday, March 5, on #tails-dev (OFTC) 9pm UTC (10pm CET) Every one interested in contributing to Tails is welcome. Redmine tickets we could discuss: * #6245: MD5 Reborned Hasher is incompatible with Firefox 20 https://labs.riseup.net/code/issues/6245 * #6679: Do not auto-connect to the #tor IRC channel https://labs.riseup.net/code/issues/6679 Usual topics on the agenda are: * Volunteers to handle broken windows this month? https://labs.riseup.net/code/projects/tails/roadmap#Broken%20window * Planning a monthly low-hanging fruits or review'n'merge meeting? Low-hanging fruits meeting: spend a while together on many small tasks that take less than 2 hours each, and are waiting in our TODO list for too long. Feel free to propose and prepare other discussion topics. Please raise them in this thread so that others can ask details and prepare the discussion too. If you want to get involved but don't know how yet, please consider coming and say hello during the meeting: this work meeting probably won't be the most adequate time and place to properly introduce newcomers to the development process, but at least it should be a fine place to tell us you're interested, and possibly to schedule a better suited event. Cheers. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Tor Launcher as a standalone XUL app in Tails
anonym wrote (19 Feb 2014 19:14:40 GMT) : The primary profile can be used offline too. For instance, if a link in some GNOME notification is clicked, Iceweasel using the primary profile will be opened. We'd some how need to make Tor Launcher *not* run when the browser is opened while offline (start with `TOR_SKIP_LAUNCH`?). But then, if the browser was opened while offline and we then connect to a network (and we are in bridge mode), then the NM hook will want to start the already running browser with the envvar that will show Tor Launcher's network settings and then exit the browser. How can all this be achieved without creating a complete mess? OK. From the top of my head, two vaguely related notes: * We'll want to run Tor Launcher *only* when the user has ticked a checkbox in the Greeter, right? Or do we run it in all cases? * Note that we don't run the browser by default on network connection. See the wrapper in /usr/local/bin/iceweasel. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Adding BitMessage and Bitcoin-QT to Tails
intrigeri wrote: winterfairy at riseup.net wrote (14 Feb 2014 15:05:56 GMT) : Electrum sounds interesting, if we want a Bitcoin client in Tails. At least, anyone who has been doing some Tails user support knows for sure there is some demand and use cases. Electrum is not part of Debian stable, but it is in Debian testing/sid. It would be good to know if it can be backported to Wheezy. Vasudev, would you be interested in having a look? (No, I'm *not* writing this with my AM hat ;) Added ticket about inclusion of Electrum in Tails: https://labs.riseup.net/code/issues/6739 ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Made New Identity work again, please review
intrigeri wrote: Hi, (Note: it would be great not to break threading: anyone reading the old thread, but not this one, will miss your reply etc. IIRC you read the list via the archives, so I understand it's a bit of a pain, but hopefully your MUA allows you to insert arbitrary References and In-Reply-To headers.) Don't think so. Sorry. 3. It might be overkill, and surely adds some code, but I would pass the port to listen on, control port socket path and authentication cookie path as command-line arguments (preferably named, not positional). Just to make it easier for others to reuse this piece of code, and increase collaboration between similar projects. A quick research showed up that this can probably be done with only a few lines of code if using the modules optparse or argparse. Python 2.6 (which Tails uses) only has optparse. In python 2.7 optparse is deprecated and replaced by argparse. This would mean writing one version for squeeze and one for wheezy. I don't think it is worth it currently. Fair enough. Care to file a ticket, blocked by #6015, so that this is not forgotten at post-1.1 time? I guess I should wait until my branch is actually accepted/merged into devel? ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Made New Identity work again, please review
winterfa...@riseup.net wrote (20 Feb 2014 11:52:17 GMT) : 3. It might be overkill, and surely adds some code, but I would pass the port to listen on, control port socket path and authentication cookie path as command-line arguments (preferably named, not positional). Just to make it easier for others to reuse this piece of code, and increase collaboration between similar projects. A quick research showed up that this can probably be done with only a few lines of code if using the modules optparse or argparse. Python 2.6 (which Tails uses) only has optparse. In python 2.7 optparse is deprecated and replaced by argparse. This would mean writing one version for squeeze and one for wheezy. I don't think it is worth it currently. Fair enough. Care to file a ticket, blocked by #6015, so that this is not forgotten at post-1.1 time? I guess I should wait until my branch is actually accepted/merged into devel? If you also mark the new ticket as blocked by the new identity one, I see little use in waiting :) Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release schedule for Tails 0.23
Hi, a week has passed since then. May we please have a final schedule? Thanks in advance! Cheers! -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Tor Launcher as a standalone XUL app in Tails
On 2/19/14, 2:14 PM, anonym wrote: It sounds to me like the setting you are talking about does *not* have any direct effect on Firefox, only on Tor Launcher. To clarify, you are *not* setting e.g. `network.proxy.socks` (which Firefox itself uses), instead you are setting e.g. `extensions.torlauncher.xxx` (which Firefox itself doesn't use). Is this correct? (If so, we're happy -- see the end of this email.) Yes, I think that is correct. It is a little difficult for Kathy and me to separate the two things because until now we have never thought about Tor Launcher running in a profile separate from the one where browsing will be done. This is also why we need to start tor with DisableNetwork=1 when the use default bridges option is enabled: so we can update the bridge configuration before tor starts its bootstrap process. See: https://trac.torproject.org/projects/tor/ticket/10418 [Note: The reason I'm continuing this part of the discussion is not because I think it will be especially relevant for Tails directly but it does help me to better understand where Tor Launcher is going in the future so I can assess if Tor Launcher in Tails is a long-term solution or not. It may be that I'm just wasting everyone's time here being confused and speculating about a future change that I don't know the exact details of, so we may want to just drop it. :)] Will anything change with Tor Launcher's current design of immediately starting Tor and configure it to use the previous settings on all runs after the very first? Otherwise I don't see the relevance of setting `DisableNetwork=1` beyond the first run; if the use default bridges option was chosen on first run, bridges will be written into torrc, which makes `DisableNetwork=1` redundant. However, if the design does change, e.g. that you show the network settings on *each* run, with `DisableNetwork=1` set (highly relevant now since the user may have chosen connect in the clear in the previous run), then I don't see why you thought this new behaviour would be incompatible earlier patch (0002-Always-open-network-settings-if-DisableNetwork-is-se.patch). I tried to explain this in my last message but possibly I wasn't clear. We do not plan to show the network configuration wizard each time. The issue is that Tor Launcher needs to reconfigure the default bridges each time tor starts up. This is necessary because the default bridge addresses may change when TBB is upgraded (the addresses are stored as a series of hidden Tor Launcher preferences). I am not sure if the concept of default bridges is something you will want for Tails in the future or not. It doubt it. In Tails we care about the bridges being non-public to support the hide that you are using Tor use case as best we can. If we expose our users to a convenient option to use a public list of default bridges, then we put the users of that use case at risk. Therefore it'd be great if whatever GUI control you'll use for this option will be hidden (or at least disabled/greyed out) if the pre-supplied list of default bridges is empty/non-existent. That is already how things work. The option to use default bridges is only displayed if the necessary preferences are present. Another small consideration is that we (TBB developers) will probably not test Tor Launcher as a standalone XUL application because we will not be using it that way... so it is possible we will accidentally break something that is needed in that mode. Of course we will try not to do so. As long as Tor Launcher more or less sticks with its current design, and continues to keep away from stuff directly affecting Firefox (leaving that to Tor Button) and only do stuff related to starting/configuring/monitoring Tor processes, I expect very little problems due to your upstream changes. Does this look like your plan for the foreseeable future? Yes, although I leave it to Mike (in his role as TBB chief architect) to comment as well. Requirements may dictate a future change in direction, but for now the plan is for Torbutton and Tor Launcher to work together but maintain their distinct roles. -Mark ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Updated release schedule for Tails 0.23 [Was: Release schedule for Tails 0.23]
13/02/14 01:22, anonym wrote: I'll be release manager for the Tails 0.23 release. Here's the preliminary release schedule: Here's an updated release schedule for Tails 0.23: 2014-03-05 Feature freeze. Tag 0.23-rc1 in Git. Build and upload 0.23-rc1 ISO and IUK. 2014-03-06 Test 0.23-rc1. 2014-03-07 Officially release 0.23-rc1. 2014-03-17 Firefox 24.4.0 ESR sources are available. Package and upload Firefox 24.4.0 ESR. Tag 0.23 in Git. Build and upload 0.23 ISO and IUK. 2014-03-18 Test 0.23. 2014-03-19 Officially release Tails 0.23. The only change is that the release date was pulled back one day since... I suppose bumping the release date by only one day instead (to 2014-03-19) is viable if I get enough assurances that others can help in the testing on 2014-03-18. ... I got enough such assurances. Thank you, all! Cheers! ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Release schedule for Tails 0.23
20/02/14 13:25, intrigeri wrote: Hi, a week has passed since then. May we please have a final schedule? Thanks in advance! Sorry, posted now. The reason I have been putting this off is that other commitments collided with 2014-03-16, when the Iceweasel sources apparently are actually available and when I technically could start preparing the release and thereby shave off one day delay for the release. I've been trying to sort out the collision but I still don't feel confident I'll be available on the 16th so I'll stick with the original date. Cheers! ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] Low-hanging fruits session: Monday, February 24
The next low-hanging fruit session is scheduled for Monday, February 24, on #tails (OFTC) at 9am UTC (10pm CET). Everyone interested to contribute to Tails is warmly welcome to join! The idea is to spend a while together on many small tasks that take less than 2 hours each. For newcomers, the list of easy tickets should be a great place to start: https://tails.boum.org/contribute/easy_tasks/ During these meetings, we exceptionally allow ourselves to do the review merge process on IRC instead of the usual email-based workflow, so this should all go pretty smoothly. signature.asc Description: OpenPGP digital signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Low-hanging fruits session: Monday, February 24
sajol...@pimienta.org: The next low-hanging fruit session is scheduled for Monday, February 24, on #tails (OFTC) at 9am UTC (10pm CET). Of course, this is 10am CET! Everyone interested to contribute to Tails is warmly welcome to join! The idea is to spend a while together on many small tasks that take less than 2 hours each. For newcomers, the list of easy tickets should be a great place to start: https://tails.boum.org/contribute/easy_tasks/ During these meetings, we exceptionally allow ourselves to do the review merge process on IRC instead of the usual email-based workflow, so this should all go pretty smoothly. signature.asc Description: OpenPGP digital signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Tor Launcher as a standalone XUL app in Tails
20/02/14 10:57, intrigeri wrote: anonym wrote (19 Feb 2014 19:14:40 GMT) : The primary profile can be used offline too. For instance, if a link in some GNOME notification is clicked, Iceweasel using the primary profile will be opened. We'd some how need to make Tor Launcher *not* run when the browser is opened while offline (start with `TOR_SKIP_LAUNCH`?). But then, if the browser was opened while offline and we then connect to a network (and we are in bridge mode), then the NM hook will want to start the already running browser with the envvar that will show Tor Launcher's network settings and then exit the browser. How can all this be achieved without creating a complete mess? OK. From the top of my head, two vaguely related notes: * We'll want to run Tor Launcher *only* when the user has ticked a checkbox in the Greeter, right? Or do we run it in all cases? It's been my assumption that we'll stick with the original checkbox in the Greeter plan. Of course, we could instead run it for each new connection (and always make sure `DisableNetwork` is set in torrc before we start Tor in the NM hook). It would actually make it harder for users that need bridge mode to make a mistake by accidentally logging in without checking the box (if there's a wired connection they're screwed by NM automatically connecting). When it comes to user experience, though, I'm not sure non-bridge users will be happy with this new, frequent pop-up that they have to deal with. In fact, it will train them to always click Connect so that they will screw themselves the time they actually need to add bridges. I think I prefer our original plan. Other opinions? * Note that we don't run the browser by default on network connection. See the wrapper in /usr/local/bin/iceweasel. Yes, I'm aware of this change. I suppose this also would have complicated things if we'd gone with the exit the browser approach. Was there anything else you had in mind by pointing this out, in case it got lost on me? Cheers! ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Updated I2P packages / persistence
16/02/14 03:30, Kill Your TV wrote:
Please pull the updated I2P packages (0.9.11) into the the Tails repo
for inclusion into Tails v0.23.
Thanks! I'll try to import these shortly.
Also, if acceptable, please consider merging the following to add
I2P to the persistence GUI.
http://repo.or.cz/w/tails/kytv.git/shortlog/refs/heads/feature/i2p-persistence
I've had a look. Indeed, adding a preset for I2P is the only thing this
branch does. Here are my remarks:
TL;DR: Just look at section 3 below, which makes a merge of this
doubtful without quite a bit of further effort.
# 1. Which path to make persistent?
This new I2P router configuration preset makes the complete
`/var/lib/i2p/` directory persistent. However, the actual I2P router
configuration lives in the `/var/lib/i2p/i2p-config/` sub-directory; are
there reasons to think that other directories can be added in the future
to `/var/lib/i2p/` (possibly by other I2P-related packages) that we not
necessarily want to include in *this* preset (for instance, we may want
separate presets)? Does it make sense to change the preset to only make
`/var/lib/i2p/i2p-config/` persistent?
# 2. Potential future issue: i2psnark and user hosted eepsites
The preset includes
`/var/lib/i2p/i2p-config/{i2psnartk,eepsite/docroot}` and as have been
discussed before in the Reviewing kytv:feature/i2p-0.9.8.1 thread,
these directories are of interest to the Live user. Currently not even
readable by it except if an administrative password is set, which at
least is documented, but this is nevertheless something we may want to
improve at some point.
I'm not sure exactly what sort of permissions game is suitable for that.
Perhaps something like a symlink `/var/lib/i2p/i2p-config/i2psnark -
/var/lib/i2psnark`, where `/var/lib/i2p/i2psnark` is readable by the
Live user and read-write for `i2psvc`? That'd also require to change the
permissions of `/var/lib/i2p`, to make it readable by the Live user.
With this setup it'd also make sense to make all of `/var/lib/i2p`
persistent like in your original patch. Note that it would be
inconvenient if we first shipped the preset as I suggest in 1, and then
like this, as changes in existing presets are not really something we
can deal with nicely between Tails releases. Whatever, I'm getting ahead
of myself. :)
Any way, my point is that if someone makes `/var/lib/i2p/i2p-config/`
persistent *now*, all such future permission/symlinking changes we may
want to introduce are lost until the source directory is removed from
the persistent media. This is of course something we could instruct
users to migrate through as a one time thing, but it'd be great to get
it right from the beginning if possible.
Also, I'm not exactly sure if this would be a problem if ACLs were used
instead. However, note that, AFAIK, aufs doesn't support ACLs so e.g.
`setfacl` would fallback to emulating the ACLs via standard permissions,
which perhaps is impossible.
# 3. Potential future issue: changes to the global router.config
We set the Tails-specific default settings in the global I2P config
(`/usr/share/i2p/router.config`), which are loaded the first time I2P is
started and written to the local configuration
(`/var/lib/i2p/i2p-config/router.config`) and, AFAIK, never looked upon
again (right?). Hence, any changes we make to the the global config in
future Tails releases will not be applied to persistent local
configurations which may break stuff for users of this feature.
This is, BTW, the same reason why we're vary of users making torrc
persistent. At least the future torrc.d feature may make that possible
to deal with for Tor.
What about solutions? I tried a quick fix, which was to remove the local
`router.config` from an already bootstrapped router configuration, and
then start I2P again in hope that it would reimport the global config
and still be able to restore the cached netDB etc. It turns out it
didn't even reimport the settings from the global config for some reason.
A slightly more involved potential solution would be, I suppose, to make
our custom I2P start script (in the Tails Git repo) to check if a local
`router.config` exists, and if so modify it so that all settings from
the global config are restored, leaving the other settings intact so I2P
won't discard the existing cached stuff or user-set stuff (the latter
may be bad, so we may only keep the minimum amount of local settings for
it to work). I haven't done a manual test but this approach actually
looks like it could work, even though it may be a bit messy.
# Merge status
1 is easy to fix, if needed. I don't want to block this obvious
improvement (e.g. not having to do a full bootstrap each Tails session
is pretty awesome) because of something that we *may* implement
*eventually*, like 2. However, if we fail to solve 3 I don't think we
can merge this. :/
Would you like to try fixing 3, KYTV, possibly with the solution I
proposed? Otherwise you can reassign ticket #5544 to me
Re: [Tails-dev] Tor Launcher as a standalone XUL app in Tails
20/02/14 16:35, Mark Smith wrote: On 2/19/14, 2:14 PM, anonym wrote: It sounds to me like the setting you are talking about does *not* have any direct effect on Firefox, only on Tor Launcher. To clarify, you are *not* setting e.g. `network.proxy.socks` (which Firefox itself uses), instead you are setting e.g. `extensions.torlauncher.xxx` (which Firefox itself doesn't use). Is this correct? (If so, we're happy -- see the end of this email.) Yes, I think that is correct. Excellent! It is a little difficult for Kathy and me to separate the two things because until now we have never thought about Tor Launcher running in a profile separate from the one where browsing will be done. Right but given the answer you gave me in the end of your email it should be pretty straight-forward. The standalone profile will only include whatever default settings are present in the Tor Launcher package itself, and the ones Tor Launcher sets during its operation (i.e. it will *not* include the TBB's settings *nor* stuff Firefox sets during its operation). However, since those are the settings you care about (currently, at least) you can reason about the standalone version in exactly the same way as when it's run as a Firefox extension. It's only when you use settings that are not exclusive to Tor Launcher that things may get problematic. This is also why we need to start tor with DisableNetwork=1 when the use default bridges option is enabled: so we can update the bridge configuration before tor starts its bootstrap process. See: https://trac.torproject.org/projects/tor/ticket/10418 [...] Will anything change with Tor Launcher's current design of immediately starting Tor and configure it to use the previous settings on all runs after the very first? [...] I tried to explain this in my last message but possibly I wasn't clear. We do not plan to show the network configuration wizard each time. The issue is that Tor Launcher needs to reconfigure the default bridges each time tor starts up. This is necessary because the default bridge addresses may change when TBB is upgraded (the addresses are stored as a series of hidden Tor Launcher preferences). Ah, now I get it. Thanks for you patience! :) I am not sure if the concept of default bridges is something you will want for Tails in the future or not. It doubt it. In Tails we care about the bridges being non-public to support the hide that you are using Tor use case as best we can. If we expose our users to a convenient option to use a public list of default bridges, then we put the users of that use case at risk. Therefore it'd be great if whatever GUI control you'll use for this option will be hidden (or at least disabled/greyed out) if the pre-supplied list of default bridges is empty/non-existent. That is already how things work. The option to use default bridges is only displayed if the necessary preferences are present. Great! Another small consideration is that we (TBB developers) will probably not test Tor Launcher as a standalone XUL application because we will not be using it that way... so it is possible we will accidentally break something that is needed in that mode. Of course we will try not to do so. As long as Tor Launcher more or less sticks with its current design, and continues to keep away from stuff directly affecting Firefox (leaving that to Tor Button) and only do stuff related to starting/configuring/monitoring Tor processes, I expect very little problems due to your upstream changes. Does this look like your plan for the foreseeable future? Yes, although I leave it to Mike (in his role as TBB chief architect) to comment as well. Requirements may dictate a future change in direction, but for now the plan is for Torbutton and Tor Launcher to work together but maintain their distinct roles. This is reassuring enough and welcome news! Now I truly feel confident that the standalone XUL approach is a perfect fit for Tails for now. Any ETA on when my patches can be reviewed? We plan to incorporate Tor Launcher in the next Tails release (0.23) which has its feature freeze on the 5th of March. If this could be upstreamed at the very latest the day before that (so there's time for us to package and test it), we'd be very happy. Of course, for that to happen the review would probably have to happen quite soon as I'm sure there'll be some back-and-forth with me revising the patches. In the worst case, if it's not upstreamed in time for our freeze, we can of course ship a patched Tor Launcher for this release and have them upstreamed for the next release or so, so it's not an imminent, hard requirement. Also, see attached files for a new patch set. From now on I won't rebase the patches any more in order to ease your review process. For the record, I've tested the patched Tor Launcher successfully both as a Firefox extension, and a standalone XUL application. Cheers! From
Re: [Tails-dev] #5594: tails-greeter: better administration password UI
06/02/14 00:31, Andres Gomez Ramirez wrote: I attached a patch for #5594: tails-greeter: better administration password UI https://labs.riseup.net/code/issues/5594 Thanks for the patch! In the patch you use at least one untranslated string in +self.warning_label.set_markup(iPassword must not be empty./i) but possibly also in +self.warning_label.set_markup(iPasswords do not match./i) In the latter case you actually set it to the default text for `warning_label` as defined in the glade file, so maybe it works. I'm no glade expert, but I think the way you'll have to go is to create two `warning_label`, one for each warning, and `show()`/`hide()` them appropriately. I'd be glad if someone more familiar with glade could chime in if there's a better approach. Cheers! ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Please review'n'merge feature/5588-no-autologin-consoles
22/12/13 20:09, intrigeri wrote:
Hi,
please review feature/5588-no-autologin-consoles and merge it into
devel, candidate for 0.23. Ticket = #5588.
There's a branch in our main repo + another one (same name) with
a snapshot version in the greeter repo, so the merge implies to
release tails-greeter 0.7.23.
Code review passed without comment.
Everything seemed to work as intended during testing. (I had to build a
new t-g snapshot with master merged into it (just for testing purposes,
not uploaded or pushed) since the one in the APT suite is so old (based
on 0.23) that t-g 0.24 is pulled instead.)
Great work!
Note that there's one potentially non-consensual in there:
[...]
* Seriously, the intended users (debugging for developers or
power-users) can
as well `loadkeys' their preferred layout.
I agree. However, typing `sudo loadkeys ${keymap}` and perhaps in
particular the password, which have no visual feedback, may be pretty
awkward even for power users that are used to some particularly non-us
layouts. :) Short of a way to change the keymap without root privileges
I suppose we're stuck with this.
Given that two months have passed without objection, I think we have
consensus.
I want to merge this, but I'm tempted to delay it until some of the
other Tails Greeter merges are also in, to avoid some of the packaging
overhead. Therefore I also leave the ticket as is until I actually merge
it. Does this make sense?
Cheers!
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Serious issue: fail-safe and hotplugging
06/01/14 16:58, intrigeri wrote: sorry for the delay, and sorry in advance for the bad mood that probably impacts this email, I'm a bit grumpy today. :) anonym wrote (31 Dec 2013 00:45:51 GMT) : 30/12/13 13:48, intrigeri wrote: anonym wrote (29 Dec 2013 21:21:35 GMT) : 27/12/13 18:05, intrigeri wrote: Approach 1 -- A seemingly obvious fix would be to move the fail-safe from its current location, tails-unblock-network, into tails-spoof-mac, which is run by the MAC spoofing udev hook when network devices are added. The fail-safe would then act on a per-device basis, and it would be closer to the spoofing, which both are nice (bonus: the problem you raised about macchanger can't retrieve the permanent MAC address would be really easy to fix). I like this approach, and I hope we can make it work fine. Let's see. [...] Let's just drop all these sub-discussions. I'm in complete agreement with you now. Approach #1 it is! Hmm. I just think I came up with a fix that makes Approach #1 robust (it can be used for Approach #2 too, but it doesn't make as much sense): we use ferm/iptables to drop all outgoing traffic from interfaces that have not been explicitly said to be ok by the fail-safe code. [...] I'm not convinced that this added code, design complexity, and thus difficulty to audit is more likely to protect our users than the lack of it. AIUI, the only bonus is for a corner case, which the potential drawbacks are for everybody. Agreed. Looking back at all this I don't know what I was thinking. I'm honestly sorry for having forced you through all this crap. But perhaps I just want to see this branch merged ASAP in some acceptable state, and am starting to get tired of thinking about it. The current state + a few documented known issues + the small fixes I've asked for a while ago, would be already much better than what our users have in hand right now. All this is done, as per my other replies. I've also implemented approach #1 and fixed #6552. See commits 7b7ba02d..e85b325. It's all pushed into feature/mac-spoof, both Tails and Greeter repos, and I've built a new Tails Greeter snapshot, uploaded it, and merged the feature branch + APT suite into experimental. In summary, tickets #6552, #6540, #6550, #6111 and #6541 are now in your court. :) Cheers! ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] [RFC] Design (and prototype) for MAC spoofing in Tails
07/01/14 19:48, sajol...@pimienta.org wrote: This is how the MAC address option looks in the Greeter: [...] I tested this option yesterday with a fellow Tails user, which is not a native. The word spoof happened to be problematic. According to the Microsoft Manual of Style, a secret reference of mine :), it is all-right to use the spoofing but it needs to be explained first if we are not sure that our users will understand it. Well... that's exactly what happened to me. [...] So here is our updated proposal: « MAC address spoofing Spoofing MAC addresses hides the serial number of your network cards to the local networks. This can help you hide your geographical location. It is generally safer to spoof MAC addresses, but it might also raise suspicion or cause network connection problems. See the documentation. [x] Spoof all MAC addresses » Thanks for you testing! The change looks good to me. Implemented in commit d1a20c4. More feedback later. ? :) Cheers! ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
