Re: [Tails-dev] PGP Smart Cards
Hi, a...@boum.org wrote (28 Aug 2012 17:29:30 GMT) : They use udev rules to solve the permission issues. However, the links to the file containing these rules is (was?) broken. FWIW, in my (not-uploaded-yet) backports of libccid, /lib/udev/rules.d/92-libccid.rules does exist. 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
Re: [Tails-dev] Block/unblock wireless devices?
Hi, intrigeri wrote (25 Sep 2012 08:15:28 GMT) : Ague Mill wrote (25 Sep 2012 07:53:02 GMT) : Bluetooth can be problematic. Some systems use Bluetooth to communicate with their keyboards and mouses. OK. Let's keep Bluetooth enabled, then :( Alternatively, how about killing Bluetooth support with rfkill at boot time iff. no (input?) device is connected this way? ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails webbrowser homepage
a...@boum.org wrote (26 Sep 2012 17:44:48 GMT) : We started to discuss this, and the most up-to-date proposal would be to point the homepage to our online website's News page, that would e.g. announce new release candidates to test etc. I'm in favor of that one. I think a prerequisite is to make the news section translatable: todo/make_the_news_translatable ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails: pcmcia / firewire / etc.
Hi, a...@boum.org wrote (26 Sep 2012 17:44:34 GMT) : We didn't reach a conclusion on this topic. The page on pcmcia is still tagged discuss. Thank you for resurrecting this discussion! It's unclear to me what exact part of it you intended to resurrect, but anyway, I guess it's good to have the whole picture in mind, and we might even manage to find a common solution for PCMCIA, ExpressCard, FireWire, and perhaps even Bluetooth. This is all about todo/protect_against_external_bus_memory_forensics, that links to: * todo/disable expresscard? * todo/disable pcmcia? * todo/disable_firewire? * If a firewire card was inserted into the slot and the bus is active, pop up a dialog and ask hey, you want to use firewire/etc.? I'm not sure it's possible to let a bus / slot enabled enough so that the kernel and udev are able to pop up such a message, while *not* allowing the inserted device to do Bad™ things. Details might be tricky to get right. I hope we don't need something that clever, implementation -wise. * disable these buses by default, allow opt-in through tails-greeter to enable I guess this would be our worst case solution, if we find nothing better. UX failure IMHO. * ask that users assert they want to use this or that bus, and make the assertion bind to a single device, rather than all devices blindly I guess that's basically the same as the per-device pop up dialog idea. * de-activate PCMCIA and ExpressCard on systems that don't have any PCMCIA or ExpressCard devices after running for 5 minutes. This is going to byte some users, but probably only the first time. I am strongly inclined towards this one, for PCMCIA, ExpressCard FireWire and even Bluetooth. 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
Re: [Tails-dev] Download manager
Hi, a...@boum.org wrote (26 Sep 2012 17:44:20 GMT) : https://tails.boum.org/todo/include_download_manager/ - [...] it might be useful to include a download managar in Tails. A usecase could be to try to download a big file across separate working sessions. I think this usecase is worth supporting, e.g. to make it easier to download ISO images such as Tails' ones. I would consider it relatively low-priority, though. I think this download manager must have a simple GUI and as few features as possible. I'm not sure what I think of Iceweasel integration. I don't intend to put much energy into that, but still, I searched a bit the Debian packages database with that usecase in mind. If so, [uget](http://urlget.sourceforge.net/) could be a good candidate. * uget - easy-to-use download manager written in GTK+: from the package long description, looks a bit too feature-full. I did not find any other candidate in Debian that integrates with the web browser. Outside of it, there are: * steadyflow - Simple download manager for GNOME: in Wheezy, not in Squeeze; a quick look at the build-deps makes me think a backport is doable. Aims for minimalism and ease of use. * multiget - graphical download manager: in Squeeze and Wheezy; from the package long description, looks a bit too feature-full. * kget: depends on many parts of KDE, so that's a no. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] please look at Comparison of Whonix, Tails and TBB
intrigeri: Hi, adrelanos wrote (27 Sep 2012 04:27:33 GMT) : I created a Comparison of Whonix, Tails and TBB Thanks a lot for doing that work! Thanks for the thorough review! I think I incorporated all your suggestions. This is of course not final and I'd change again if anything is still incorrect. I must say I'm very happy to see someone explore the gateway / workstation design both practically and theoretically -- we still have not made up our mind on that one within Tails, and current hardware is probably not ready for it yet in a Live system setting, but I do believe that the work that happens on this topic in Whonix today will benefit Tails in the future. Nice to be of service. :) There is a another research project ongoing (for Tails ;). Qubes OS with a strong security by isolation concept. Got so far very good feedback. http://qubes-os.org/ Offers much stronger protections than Virtual Box. After a quick look, Tor isolation is also good. http://theinvisiblethings.blogspot.com/2011/09/playing-with-qubes-networking-for-fun.html Disadvantages are, that it does not run on top of Debian. Ok, not a real disadvantage but hard if you are accustomed to Debian. It's a complete operating system, they say more like a Xen distribution with Fedora. And it has even higher hardware requirements. http://wiki.qubes-os.org/trac/wiki/HCL If there is anything wrong, I'll correct it right away. Generally, I found this comparison just fine, but perhaps a tiny bit too simplistic, and unfortunately it looks like those simplifications always happen in the same way: e.g. for Protection against root exploits, Whonix gets a Yes, Tails gets a No... and one has to read the footnote to understand this is about root exploits in Whonix-Workstation only. See what I mean? I acknowledge it's probably much harder to root the Whonix-Gateway than Tails, but still... That is now hopefully clarified. Another similar occurrence is the Amnesic security property comparison. I find it misleading to state that it is an Optional Feature (via VM snapshots, pointing to a barely documented process) in Whonix, and a Yes in Tails, as if it was the same kind of amnesia. For the former, it's let's hope the host OS won't write my secrets to disk, right? While for the latter, it's a basic design principle, that I think is pretty well enforced. Feel free to tell me I should read the Whonix design doc, if I'm totally wrong on that one :) Fixed. About IP/DNS protocol leak protection and Icedove (Thunderbird) leaks the real IP address: I do acknowledge the Whonix way (the workstation apps don't know the IP address at all) gives additional by-design protection, but please make it clear that such leaks are made now waaay less likely in Tails since we dropped transparent torification. Fixed. More generally, I suggest that you define the compared security properties next to the comparison tables, else I already imagine less technical users, reading that Tails gets a No for Hides hardware serials, conclude that Tails sends hardware serials over the Internet by default, and go crazy on our web forum. I'd rather avoid that. It should now be clarified. ^2^ In case Tails gets rooted, the adversary can simply run ifconfig and see the user's IP. Or he could tamper with firewall rules and bypass them. I'm not sure how useful it is to mention the ifconfig trick, given 1. it's a bit misleading to put it like that, as in most cases, it will provide a mostly useless RFC-1918 address Agreed and therefore removed it. 2. the second attack (breaking the firewall) is easy and always works. Improved that. About pidgin leaks the real IP: it would be very nice of you to mention that this bug only existed in Git, and no released version of amnesia was affected. Added. Second, I've not studied all of Whonix design doc yet, so I beg your pardon if my question is naive: in case the Whonix gateway's firewall was not started / erroneously configured due to some tiny studid mistake (like the one that amnesia bug was about), what prevents Whonix workstation from connecting in the clear to the Internet (without going through Tor)? Gateway has two (virtual) networks cards. eth0 for connecting to the internet eth1 is an isolated internal network to the Workstation The Workstation has only one (virtual) network card. eth0 for connecting to the isolated internal network to the Gateway. ip-forwarding and ipv6 disabled in kernel. A mistake in the firewall rules will prevent the eth0 interface from getting up, since the firewall is started with pre-up. https://github.com/adrelanos/Whonix/blob/master/whonix_gateway/usr/local/bin/whonix_firewall https://github.com/adrelanos/Whonix/blob/master/whonix_gateway/etc/network/interfaces Even if there were no firewall at all on the Gateway, only Tor's Ports would listen on eth1. And without Tor being down, nothing would listen on eth1. The Workstation could
Re: [Tails-dev] Shipping a 686-pae kernel
Hi, Ague Mill wrote (28 Sep 2012 15:27:18 GMT) : So my hack have been to add a call to `dbus_thread_init_default()` in the initialization of the Python `dbus` module. And it looks like it solve the issue. I have not been able to get the installer to crash after installing the modified `python-dbus` package. Congrats for the debugging and for finding this hack! From what I can read from the documentation, except a performance hit, there should be no other downsides to it. The binary `python-dbus` package is fairly small (226 kB) and at this time, it's a patch I feel we can carry on. What's your opinion? Should I proceed in adding a custom `python-dbus` to the multikernel branch? Please proceed: at least so that we can verify that this hack workarounds the bug in various settings. I'm fine with shipping a patched python-dbus in Tails (obviously, as long as we report the bug and forward the patch at least to Debian). 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
Re: [Tails-dev] Please review bugfix/default_search_engines
Hi, Ague Mill wrote (28 Sep 2012 10:12:33 GMT) : Done. Have a look at commit d3ebdba5. Static review: I like it, but the use of LANG as a loop variable name, which seems to be an unecessary risk to me, when a variable that causes less side-effects could be used just as well. I'll change the name, build a test ISO and merge soon :) Added to the branch, then (commit 5ba8642). That did not work without another changes (commit 966f639). Oops, sorry. Thanks a lot for catching my mistake. 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
Re: [Tails-dev] Improvement of the shutdown sequence
Ague Mill wrote (28 Sep 2012 10:46:45 GMT) : On Tue, Sep 25, 2012 at 11:04:58AM +0200, intrigeri wrote: Ague Mill wrote (24 Sep 2012 16:03:58 GMT) : I'd be happy to get reviews of what is in feature/shutdown_cleanup. Merged into devel! ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review bugfix/default_search_engines
Merged into devel and stable :) ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Disabling 'PC speaker'?
Ague Mill wrote (06 Sep 2012 20:47:02 GMT) : On Fri, Aug 24, 2012 at 09:19:41AM +, Ague Mill wrote: I would like to blacklist the 'pcspkr' module. It is responsible for making the old-style 'PC speaker' work. On some computers, having the module loaded means loud beep at bootup, shutdown and when using the console. The idea is already to start Tails with a muted soundcard. Does anyone see a reason not to kill the 'PC speaker' as well? Implementation is straightforward, it's a new file in /etc/modprobe.d/no-pcspkr.conf with: blacklist pcspkr (I'll push that change after 0.13 is released if no one cares.) Tracked as https://tails.boum.org/todo/disable_pc_speaker/. Implementation in `feature/disable_pc_speaker`. Merged in experimental. Candidate for the release after 0.13. Merged into devel. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review bugfix/fix_background_readahead
berta...@ptitcanardnoir.org wrote (24 Sep 2012 09:28:28 GMT) : Tested, works, merged into devel. That was not pushed, apparently. I did it for real. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review feature/assymetric_gpgApplet [sic!]
Hi! Once again, I had to search my mailbox to find the status of this task (sorry, I'm ill today and my memory is bad). How about creating a ticket page for it? ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Shipping a 686-pae kernel
anonym wrote (06 Sep 2012 09:18:03 GMT) : 05/09/12 23:38, anonym wrote: 04/09/12 14:52, intrigeri: So, I just merged the feature/multikernel branch into experimental. Built and so far tested in VirtualBox. I forgot to say that this pushed the amount of RAM required to build Tails in-memory to over 6 GiB (at least when using Vagrant) so I pushed commit 974805d to bump it to 7 GiB. These Vagrant / memory tweaks made in the feature/multikernel branch should be re-done there, as they conflicted with those made in feature/vagrant and since then merged into devel, which I've just merged back into feature/multikernel. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Please review feature/early_skip_unwanted_packages
Hi, this branch prevents some unwanted packages to be installed at all, rather than uninstalling them later. This should speed up the build a bit. Candidate for 0.14, has been living in experimental for a while. No ticket, sorry. I'll create it if needed after the first review round. 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
