Re: [Tails-dev] Round of translation uploads
intrigeri: Ague Mill wrote (14 Nov 2012 15:30:55 GMT) : I have done a round of translation uploads for liveusb-creator, tails-persistence-setup and tails-greeter. Unfortunately, I am waiting for the access rights to update their respective Git repository. (I can probably send bundles or publish somewhere if needed.) If the access rights problem is not fixed shortly (as in within 2 days), then publishing your changes somewhere would ease the next steps of the 0.15 release process. Changes pushed. -- Ague pgpT7tLrFypkv.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails: pcmcia / firewire / etc.
intrigeri: The issue about the exact delay that was raised (5 minutes starting when, 1 minute starting at the same time as GDM, anything else?) is still in need of a conclusion. One minute is enough for the oh, I forgot to plug in the network card case. I'd still be more in favor of 5 to handle to the oh, I forget to plugin in the card used to hook up the scanner case. Five minutes are not a long window. If someone jumps one you while you are using Tails, you have a problem anyway. So this is meant to protect from attacks that can happen while you are on a short break. And I think your attention is probably going to be focused on Tails for at least 5 minutes after it has started. -- Ague pgp9fU7Y58jGG.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Heads-up: experimental has been rebased (was: config/chroot_local-packages is now deprecated)
Ague Mill: Please note that `experimental` has not been touched yet. It should probably be reset and rebased from that point. I'll take care of it in the next days if no one beats me to it. I have just reseted experimental on top of devel and merged again the following branches: * bugfix/bridge_mode_vs_tor_restarts * bugfix/gpgApplet_menu_in_bottom_panel * bugfix/handle_apt_sources_for_rc * feature/unsafe_browser_name * feature/sinhala-font I hope I have not missed anything. The result builds a usable image. -- Ague pgp5lxOWMKd6K.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Please review bugfix/handle_apt_sources_for_rc
Hi! The sources.list generator did not know how to handle release candidates properly. I believe the issue fixed in bugfix/handle_apt_sources_for_rc. -- Ague pgp5i2lFQM6zN.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Trying tails-create-iuk
Hi! I have tried to use tails-create-iuk under Tails itself. First there is two missing dependencies: libdevice-cdio-perl and squashfs-tools. If we don't want them on Tails, maybe tails-create-iuk should be shipped in a second binary package. Relative paths did not work as argument to --old-iso and --new-iso. It said: `++WARN: could not retrieve file info for 'tails-i386-0.14.iso': No such file or directory`. I had to use absolute path to make it run. The --tempdir option seems broken. I originaly believed it could be used to prepare the squashfs image in another directory than a tmpfs (when memory is tight) but it looks like I'm mistaken. When it was unable to find mksquashfs, it stopped and left all tmpfs and loop mounts around. I was not able to complete the process though. The further I have been able to go is complete the squashfs creation (it outputs the summary). Then I see: Use of uninitialized value $_[0] in join or string at (eval 496) line 126. Internal error: open(, -|, bsdtar, -x, --no-same-permissions, --to-stdout, --fast-read, --file, /media/crypto/tails-i386-0.14.iso, live/initrd.img): Do not expect to get 10 arguments at (eval 496) line 126. cannot remove path when cwd is /tmp/y0XQ7qssJb for /tmp/y0XQ7qssJb: at /usr/share/perl/5.10/File/Temp.pm line 902 I have not been able to locate a verbose option, so I don't have any more details. -- Ague pgpcm7K8pXIL4.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Trying tails-create-iuk
intrigeri: Ague Mill wrote (15 Nov 2012 11:44:52 GMT) : I have tried to use tails-create-iuk under Tails itself. Thanks a lot for all this useful feedback. I think it's the first time someone else than me tries it. I'm going to look at this one of these days, hopefully shortly. May I ask what kind of system you used as a testbed? Debian stable or testing? I have tried to generate the IUK from a running Tails, version 0.15~rc1. So that's probably closer to Debian stable. ;) Did you run t-c-i as root, using sudo, or what? (Honestly, I don't remember exactly what kind of credentials is needed / supported.) Using `sudo`, as the suggested in the documentation. I have not been able to locate a verbose option, There is none. It might help to install libcarp-always-perl and run t-c-i this way: $ perl -MCarp::Always path/to/tails-create-iuk What are the expected effects? -- Ague pgpg6ScSbFh53.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] network.proxy.socks_remote_dns and localhost
Hi! Since we now include Torbrowser patches, we gained the `network.proxy.socks_remote_dns` preference. Its implemented in: https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-patches/firefox/0016-Prevent-WebSocket-DNS-leak.patch When this option is true, Firefox will fail every name resolving request that is not going through a proxy (except when asked the noop that is resolving an IP address). socks_remote_dns is set to true by Torbutton. This is currently seen as mandatory: when set to false, Torbutton assumes we are out of Tor mode and display a broken onion. This state of affairs currently breaks (at least) two things in Tails 0.14: * Access to the I2P router console through `http://localhost:7657/`. * The Monkeysphere extension is not able to connect the validation agent. (This one also requires a new whitelist rule in FoxyProxy to fully work again.) Both can be fixed by using `127.0.0.1` instead of `localhost`. That's good enough if there's not an army of similar issues behind. But given that Tails system resolver is using Tor, this already takes care of the leaks that `socks_remote_dns` prevents. So we could also modify Torbutton think good things about our torrified system resolver. What do you think? -- Ague pgpwOeuIADCq5.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Bookmarks persistence - help needed
intrigeri: Ague Mill: `feature/persistent_bookmarks` confirmed working and merged in `devel`. I'm very happy 0.15 will have this feature. Nitpicking: did I miss the call for review? That feature was implemented by Alesandro. I took care of the review. The branch that was pushed was in a temporary state because it was waiting for Tails 0.14 as an upload of tails-persistence-setup was needed. I took care of the package upload, removed the now integrated patch from the branch, checked once more that it was working as intended. Do you think an extra review is required in that case? -- Ague pgpW8Hk94fb23.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] config/chroot_local-packages is now deprecated
intrigeri: Ague Mill: Your last commit (ba704e641ca) means that currently, we will build with live-config/3.0.12-1 and live-boot/3.0~b7-1. Really? I'm sorry if it's the case. This was not my intent. After testing, it's not the case. Sorry for being confused. (This probably means that the current number of rules interacting in apt/preferences is now too big to fit in my small brain.) -- Ague pgpozJDwYUnlO.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Round of translation uploads
Hi! I have done a round of translation uploads for liveusb-creator, tails-persistence-setup and tails-greeter. Unfortunately, I am waiting for the access rights to update their respective Git repository. (I can probably send bundles or publish somewhere if needed.) -- Ague pgpVP1MbI2O5a.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] network.proxy.socks_remote_dns and localhost
intrigeri: Ague Mill wrote (14 Nov 2012 09:34:46 GMT) : Both can be fixed by using `127.0.0.1` instead of `localhost`. That's good enough if there's not an army of similar issues behind. But given that Tails system resolver is using Tor, this already takes care of the leaks that `socks_remote_dns` prevents. So we could also modify Torbutton think good things about our torrified system resolver. What do you think? I propose we fix the Monkeysphere and I2P -related issues by using 127.0.0.1 instead of localhost -- and if many similar issues arise later, then we can still consider patching Torbutton. Agreed. Please review bugfix/i2p_console_bookmark and bugfix/monkeysphere_post_torbrowser branches. -- Ague pgpQT7Q3dKrC9.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Bookmarks persistence - help needed
intrigeri: But, I'm sure that *giving a chance* to other Tails developers to look at a new feature *before it's merged*, without them having to follow each development iteration, should be something we take seriously: this is something I feed is needed to happily work together, to make it easier for less-involved people to participate, and to make our stuff better thanks to others' different skills and PoV. The ticket was updated with the `todo/qa` tag in commit 9ce564b69a0 on Oct 15th (nearly a month ago). It was labeled Candidate for 0.15. The same day, I had merged the branch in experimental and announced it on tails-dev, see: https://mailman.boum.org/pipermail/tails-dev/2012-October/001884.html The documentation was subsequently edited by sajolida two days later: https://mailman.boum.org/pipermail/tails-dev/2012-October/001895.html I am sorry that you missed it. -- Ague pgp9KygLgtH6d.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] incremental upgrades: phase one almost done, release plan
intrigeri:
3. Apply that patch to fix our newly-hardened firewall configuration:
diff --git a/config/chroot_local-includes/etc/ferm/ferm.conf
b/config/chroot_local-includes/etc/ferm/ferm.conf
index 234aa04..cd36159 100644
--- a/config/chroot_local-includes/etc/ferm/ferm.conf
+++ b/config/chroot_local-includes/etc/ferm/ferm.conf
@@ -35,6 +35,7 @@ domain ip {
}
daddr 127.0.0.1 proto tcp syn dport 9062 {
mod owner uid-owner htp ACCEPT;
+mod owner uid-owner tails-iuk-get-target-file ACCEPT;
}
# White-list access to Tor's ControlPort
Is there any reasons not to fix this before 0.15~rc1?
--
Ague
pgp3wsDyj5XRt.pgp
Description: PGP signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review and merge bugfix/no-console-setup-on-X
intrigeri: intrigeri wrote (12 Nov 2012 16:35:20 GMT) : I'll be back if I see it again. I can reproduce it by issueing sudo su - in a non-root terminal. So, I'm bringing my merge request back. I don't this how this could break anything and it solved your problem in my tests. Merged. -- Ague pgpW1iBDBZy4c.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review and merge feature/korean_input
intrigeri: please review and merge (into devel): branch: feature/korean_input ticket: todo/korean_input_system Tested, as in if I choose Korean language in Tails greeter, then I get a SCIM applet in the panel, in which I can choose the Hangul input method. We've got someone willing to test early ISO images once they're out (I guess that would be 0.15~rc1 or something). Looked fine to my untrained eyes. Merged. -- Ague pgpyvHJopS1HM.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review and merge feature/hpijs
intrigeri: branch: feature/hpijs ticket: https://tails.boum.org/todo/install_hpijs/ Candidate for 0.15. Short log: 05b1b35 Install HPIJS PPD files. Merged. -- Ague pgptFgc9tkh1H.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails 0.15 release schedule
intrigeri: Ague Mill wrote (02 Nov 2012 10:29:43 GMT) : I'd like to propose the following: * November 13th: freeze and RC1 * November 20th: Firefox ESR is out * November 22th: RC2 * November 27th: Tails release The freeze should happen tomorrow (14th) evening. Hopefully the release candidate will be out the next day. -- Ague pgpdLHc0Y9dYa.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review and merge feature/obfsproxy
anonym: 12/11/12 15:11, anonym wrote: 03/11/12 09:08, intrigeri wrote: Hi, anonym wrote (02 Nov 2012 20:26:34 GMT) : Basic (perhaps even experimental as it currently lacks documentation) support for obfsproxy has been added in the branch feature/obfsproxy. Please review and merge it into devel. We agreed at the Tails summit to not merge new features before their documentation is ready. For the record, this is what allows us to squeeze the delay before feature freeze + RC1 and RC2, because it's now dedicated to translation work, rather than (like we used to do) to doc writing + translations. Now done: I should perhaps have pointed out that I'd really to see this branch merged for Tails 0.15. Confirmed working. Merged. sajolida: I suggest you have a look at the changes in user documentation, but they are good in my eyes. -- Ague pgpDmsYHLXfF8.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Bookmarks persistence - help needed
Ague Mill: On Thu, Oct 11, 2012 at 11:11:14PM +0200, Alessandro Grassi wrote: Yes, it is too late. But don't worry, 0.15 should be out early December. :) That gives us a little more room to have the documentation well polished and delivered with more translations. Fine. I made a new patch for documentation, and symlink patch is fixed to create the bookmarks folder. All the needed patches are attached. Wonderful! Everything works fine according to my tests, so I have pushed your work in the `feature/persistent_bookmarks` branch and merged it in experimental. Please note that I did not upload a customized tails-persistent-setup and relied on a patch instead, as I wanted to leave tails-persistent-setup alone until 0.14 is out. New package built and uploaded. `feature/persistent_bookmarks` confirmed working and merged in `devel`. -- Ague pgp7YMF2fwsXG.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] config/chroot_local-packages is now deprecated
Hi! The current `devel` branch now fetches all binary packages from our APT repository. From now on, `config/chroot_local-packages` should only be used for internal tests and external branch reviews. A `README` file is there to remind you that. See the following page on how to upload packages and general repository usage: https://tails.boum.org/contribute/APT_repository/ This is a very welcome step toward splitting the main Git repository, and proper source distribution. Hurray! Please note that `experimental` has not been touched yet. It should probably be reset and rebased from that point. I'll take care of it in the next days if no one beats me to it. -- Ague pgppTK5Iri7fr.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Idea or something
(CC'ing you. I don't know if you are subscribed.) Hans-J. Ullrich: Although everything is sent over TOR, I think you should make sure, the MAC- address of every network device should be changed at boot. You ca do this by macchanger. See https://tails.boum.org/todo/macchanger/. Feel free to provide patches. Wireless cards and network cards (wlan0 and eth0) should at least got a changed MAC-address, but also should every new device get a new MAC (i think of bluetooth or usb-3g-devices). Feel free to tell us how to do the later. Has tails a firewall active? (iptables). If yes, it should be completely (and mean COMPLETELY) closed, and should be opened by the user when he is needing it. This question shows that you have hardly done any research before asking. Please look at Tails documentation https://tails.boum.org/doc/index.en.html and contribute section https://tails.boum.org/contribute/index.en.html. -- Ague pgph9GE9AIFyS.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Call for testing 0.14~rc2
anonym:
07/11/12 18:10, intrigeri wrote:
Note for the one who manages the release: we need to make sure the
final ISO does not get the latest live-config (3.0.9-1): it has
basically nothing useful for us, and it migrates to new paths brought
by live-boot 3.0~b7, which we're not ready for yet (details:
todo/newer_live-boot).
I'll put live-config{-sysvinit} 3.0.8-1, both which worked well in
0.14~rc1 and ~rc2, in config/chroot_local-packages. Unless there is some
other suggestion (APT repo?).
Please use the APT repository from now on. Oh, and don't forget to
upload the source! :)
I intend to remove all packages in the Git repository for 0.15, so
let's just start the good habits now...
--
Ague
pgpzwVV4Hcloc.pgp
Description: PGP signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails 0.15 release schedule
intrigeri: FWIW, I'm trying to get this in 0.15 too: [...] My personal goals: * Even if the memwipe seems way better now, I'd like another shot on feature/hugetlb_mem_wipe as the user experience is better with a progress bar. I'll need help for the tests. * Empty chroot/local_packages and use our APT repository instead. * Upgrade at least HTTPS Everywhere and if possible NoScript. -- Ague pgpNiE8EERrhE.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Progress report on the automated test suite
anonym: I'd like to start by saying that I think the work bertagaz did on the jruby + sikuli + cucumber combo is really great. He called it PoC, but after having worked on it for some time now I say it's definitely fit for the task at hand. Great. :) Next I'd like to announce that the automated test suite, in its current unfinished state, actually has found its very first Tails bug. Here's the cucumber output of when it was found: [...] And all Internet traffic has only flowed through Tor # cucumber/iceweasel/step_definitions/torified_browsing.rb:66 The following IPv6 hosts were contacted: ff02::1 Full network capture available at: [...censored...] There were network leaks! (RuntimeError) [...] In other words, our firewall leaks link-local IPv6 broadcasts even though it should block everything IPv6 (right?). This is promising (not that Tails has this particular bug, but that the test suite found it)! I did not run the code itself, but are you sure that these packets came from Tails and not from the host system? Saving/restoring VM snapshots = This is how I intend to use it for a given feature: Background: Given I restore the background snapshot if it exists [ ... real background steps ... ] And I save the background snapshot if it does not exist [ ... Scenarios ... ] Those lines feel like noise: they are an implementation detail and should not appear in the scenarios. Cucumber offer tags and hooks that should be usable to achieve something similar while keeping the scenarios as lean as possible. See: https://github.com/cucumber/cucumber/wiki/Hooks and http://stackoverflow.com/questions/9994797/cucumber-when-to-use-tags-hooks-vs-backgrounds An issue with restoring past state like this is that our Tor's circuit state may get out-of-sync with the circuit state of the relays they use. For instance, I ran 10 tests that restored to the same post-background state and all but the first two failed to fetch a web page. Then I ran 10 tests where I do the following after each snapshot restore: 1. Stop Tor. 2. Sync time from host to guest. 3. Start Tor. And then all 10 tests succeeded, so it seems resetting Tor like this is highly necessary. Indeed, as restoring from a snapshot is likely to break all existing TCP connections. Have you tried to see if a SIGHUP sent to Tor is sufficient? Side note: your `try_for` function is very unidiomatic Ruby. I suggest you have a look at the part about blocks on http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_containers.html, and the `yield` and `block_given?` methods. -- Ague pgp4LnUB9l9Af.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Post-0.14 release schedule
intrigeri: since we now build our own web browser, I propose we switch to our ideal documented release schedule [1] for the release after 0.14. This would mean: * November 6th: freeze and RC1 * November 20th: Firefox ESR is out * November 22th: RC2 * November 27th: Tails release Given November 6th is the scheduled release date of 0.14, I think we should not release RC1 at the same time. As you said, it looks like there will not be a huge amount of new features, so we can probably shorten the time to test RC1. I'd like to propose the following: * November 13th: freeze and RC1 * November 20th: Firefox ESR is out * November 22th: RC2 * November 27th: Tails release I think the release is ought to be called 0.15 because we'll have at least persistent browser bookmarks. Any other ideas? -- Ague pgpEQQXIyRv5p.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] [PATCH] Remove the last absolute path in our SYSLINUX config
intrigeri: Ague Mill wrote (20 Oct 2012 16:31:14 GMT) : Both works. Great! So, I think next steps are: 0. someone else tests the patch a bit and ACKs it: I'll do it 1. a ticket is created to remind us to upstream this later Done: https://tails.boum.org/todo/upstream_use_of_relative_path_in_syslinux_config/ 2. the release manager decides if he wants to merge it -- Ague pgpdKaMjVigoE.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Debian popularity contest
adrelanos: The Debian *popularity-contest* package popcon is **disabled** Tails. [...] Letting Tails users vote in popcon in a privacy friendly way is a desirable goal. Sorry but I don't think everyone will agree on that. Most would say that Tails should send as little as possible information on its users to the world. Thanks for the detailed analysis... but unfortunately I think it's unnecessary. Occam's razor often leads to more readable documentation. -- Ague pgp4e07euQvpv.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] torbrowser.version vs. torbutton [Was: Tails 0.14 vs. iceweasel 10.0.9esr-1]
intrigeri: So, I'm wondering what version number we should set in our own torbrowser.version. Hence, I've investigated how exactly torbrowser.version affects torbutton behaviour. My results follow. I'm no JavaScript programmer, so I really feel like another pair of eyes should do the research (if possible independently), and report back (and, why not, compare with my results -- else I'll do it). [...] = Given torbrowser.version is only tested in boolean context for getCharPref, I think we can just set any string that is true in this context, such as (I guess), Tails. I confirm your analysis and I think setting the version to Tails is a good choice for now. -- Ague pgpWMfpWMrPXO.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Iceweasel backports experiments
intrigeri: berta...@ptitcanardnoir.org wrote (20 Sep 2012 17:30:51 GMT) : On Thu, Sep 20, 2012 at 01:26:23PM -0400, Robert Ransom wrote: On 9/20/12, berta...@ptitcanardnoir.org berta...@ptitcanardnoir.org wrote: I've imported all of them but four that I felt weren't necessary: * 0007-Make-Tor-Browser-exit-when-not-launched-from-Vidalia.patch Do not omit this patch. But in Tails, the browser isn't started by vidalia. Is there another reason I don't get? Yes, but I only understand it now. Or at least, I think I do. This patch prevents us from running a torbrowser-like Firefox (in our case, iceweasel + torbrowser patches) without the torbrowser.version variable set. That combination does not make sense, and probably never got any serious exposure to testing = we do want to have the torbrowser.version variable set, and this patch will be our safeguard, making sure we don't drop the variable by mistake some day. Did you have specific ideas for the Unsafe browser while writing that? If I understood correctly, having that patch applied in our binary means we will need to set 'torbrowser.version' even for the Unsafe browser. This might not be a problem in itself, but this would be quite confusing, wouldn't it? -- Ague pgpuc0DGumB6k.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails 0.14 vs. iceweasel 10.0.9esr-1
intrigeri: ... and anyway, I'd rather go with option 3 (iceweasel + torbrowser patches in temporary APT repostory) or maybe even option 4 (tbb's torbrowser). anonym: How realistic is the following option? 3. Ship new Iceweasel esr + relevant TorBrowser patches that we build ourselves and host on some temporary APT repo so Torbutton becomes good? I don't remember exactly where bertagaz left his experiments in this field, but at least the package building part looked mostly done, no? If it is so, on the infrastructure side, setting up a temporary APT repository is easy. I guess I could get something ready (binary packages + repository + branch merged into experimental) for the end of next week -- help would be more than welcome on the package building and testing side, though. (To what degree the result would be hackish and temporary, I don't know -- depends on the time I manage to gather for this task, and the help I get.) Also, IIRC, Ague veto'ed this solution last time we faced a similar issue, but I admit I don't remember why. Ague? My fear is: this repository is not going to be temporary. It looks like we are going to end up with a blurry process, and more migration work from our current mess. But well, if you want to do to it and deal with the aftermath... feel free. -- Ague pgpBLwK1Xmt37.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] [PATCH] Remove the last absolute path in our SYSLINUX config
Hi!
I would like to see the attached patch included in 0.14~rc2. I have
tested it to work on both a DVD and a USB sticks created by our USB
installer.
Removing all absolute paths in our SYSLINUX config has the advantage
that to convert the configuration from ISOLINUX to SYSLINUX, the
directory name is the only thing that actually needs to be changed.
This could be helpful to the Universal USB Installer developers to fix
the present breakage of Tails support.
--
Ague
From 93253110525663a67111240c6c1e6e110ce3bf25 Mon Sep 17 00:00:00 2001
From: Tails developers amne...@boum.org
Date: Sat, 20 Oct 2012 15:16:16 +0200
Subject: [PATCH] Remove the last absolute path in our SYSLINUX config
---
config/binary_local-hooks/10-syslinux_customize |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/config/binary_local-hooks/10-syslinux_customize b/config/binary_local-hooks/10-syslinux_customize
index 936c30f..c6565ec 100755
--- a/config/binary_local-hooks/10-syslinux_customize
+++ b/config/binary_local-hooks/10-syslinux_customize
@@ -53,3 +53,5 @@ EOF
sed -i -e '/^include stdmenu\.cfg/a include tails.cfg' ${CFG_FILE}
+# no need to use absolute paths to find splash images
+sed -e 's,/isolinux/,,' -i ${SYSLINUX_PATH}/stdmenu.cfg
--
1.7.2.5
pgpSyYHoNilfn.pgp
Description: PGP signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails 0.14 vs. iceweasel 10.0.9esr-1
On Sat, Oct 20, 2012 at 06:02:08PM +0200, intrigeri wrote: Ague Mill wrote (20 Oct 2012 15:54:08 GMT) : Before we decide to completely rule this out, I would really like someone with enough energy and processing power to confirm that the last Iceweasel package + TorBrowser patches + Torbutton will produce a working browser. Sure. I'll do that on Sunday or Monday if nobody has done it before. Good! :) Oh, BTW, why does this script replace Debian's torbutton with the TBB's one? Any reason I should do the same when testing iceweasel + torbrowser patches? Debian #690729 against Iceweasel reads: So please add a 'Breaks: xul-ext-torbutton' relationship to the next ESR upload. I will ask the removal of xul-ext-torbutton once the later will have landed in Wheezy. So I assumed the Debian package would be gone before long and that it was better to stick with what was shipped in TBB (and thus tested as compatible with TorBrowser). I could have done the same for HTTPS Everywhere, but the Debian package enables CACert rules by default which is something that is also worthwhile to have in Tails. Mh... and while writing this, I am realizing that this can be used for fingerprinting. Ah, well... risks against risks, I'd rather have our users use more HTTPS. -- Ague pgpaxhAqejoXD.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] [PATCH] Remove the last absolute path in our SYSLINUX config
intrigeri: Ague Mill: I would like to see the attached patch included in 0.14~rc2. I would like too. Thanks for tackling this. I have tested it to work on both a DVD and a USB sticks created by our USB installer. If this was not done yet, I think these other tests should be performed: installing an ISO (built with this patch) on a USB stick using isohybrid + cat, boot it, clone it onto another USB stick with our USB installer, boot that one. Both works. -- Ague pgpxFvpOE7Jw1.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails 0.14 vs. iceweasel 10.0.9esr-1
On Thu, Oct 18, 2012 at 01:19:41PM +0200, anonym wrote: What do we do for 0.14? I suppose our (realisic) options boil down to: 1. Ship an old Iceweasel esr with good Torbutton. 2. Ship a new Iceweasel esr with bad Torbutton. How do we value susceptibility to general browser exploits vs. susceptibility to Tor-specific anonymity attacks? I think I'm more in favour of option 1, but I feel far from confident with this choice. How realistic is the following option? 3. Ship new Iceweasel esr + relevant TorBrowser patches that we build ourselves and host on some temporary APT repo so Torbutton becomes good? I needed to explore a 4th way... and it looks like I have successfully created a monster. Running the attached script in Tails 0.14~rc1, removing `~/.mozilla` and launching `/usr/local/bin/firefox` starts something that looks a lot like a working TorBrowser. It's alive! Probably this can be turned in a chroot local-hook, but I won't waste the effort if others feels that's too much of hack. Known issue: the localized searchplugins are not currently loaded. And there is probably a bit more testing that needs to be done. -- Ague install-tbb.sh Description: Bourne shell script pgpG3IPSHqqh2.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Images on doc/first_steps/persistence/configure broken in offline documentation
On Wed, Oct 17, 2012 at 06:07:03PM +0200, sajol...@pimienta.org wrote: On 15/10/12 19:38, Ague Mill wrote: The source for the `doc/first_steps/persistence/configure` pages contains: div class=imageimg src=../stock_folder.png//div Unfortunately, this relative path will not work for offline documentation. Is there a problem in using ikiwiki's [[!img]]? After some quick grepping, it looks like this is the only page with that problem. I played around for a while when first coming up with this technique for the “Introduction to GNOME and the Tails desktop” page. But yes, indeed the img tag can be replaced by an [[!img directive. Fixed everywhere by commit 41197c8. Great! -- Ague pgpn42jGEhy4S.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Dependencies between persistence options
Hi! While testing persistent Network Manager connections in the field, I got bitten by the fact that I had not enabled GNOME Keyring at the same time. I hardly see an interesting case where someone would not want to enable both at the same time. Fixing this user experience issue would, on first thoughts, require adding support for dependencies between options in tails-persistence-setup. This would probably make at least the UI more complex (only example I can think about is Synaptic). Would it be the only option to benefit from such feature? Is there other in the radar or on anyone's mind? -- Ague pgpshyuz47sJe.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails: pcmcia / firewire / etc.
On Mon, Oct 15, 2012 at 02:47:05PM +, Abel Luck wrote: intrigeri: Hi, Jacob Appelbaum wrote (13 Oct 2012 11:02:17 GMT) : As this is a modular kernel - is there a reason not to simply add a enable firewire widget? There are several I can see: * It is a UX failure every time someone has to go out of their way to have Tails work with their hardware. * Every such widget we add to Tails Greeter makes the greeter worse for every Tails user: more cluttered, more complicated. That's why I still prefer the let's guess what the user wants approach: if they plug a device in the X slot, that's probably because they want to use it, so let's keep the X bus enabled, and disable it else. OTOH, I understand your concern, and I now think the 5 minutes delay that was suggested may be a bit too long. We did not specify exactly when the 5 minutes countdown starts, anyway. Perhaps we could start an initscript right after GDM, have it sleep 1 minute, and then disable these dangerous buses if unused? (This gives a clear visual indication of when the countdown starts.) Regardless of the solution proposed above, would it be possible to have an alternate grub menu that disables these dangerous interfaces from the get go? Please note that Tails is using SYSLINUX at the moment and not GRUB. There could be an Advanced grub menu entry, that displays these alternative kernel-param boot options. Surely, there should be *some* secure option where the window of attack is zero? How would you label it so that it does not puzzle users who are using a FireWire external disks, but never had to think about the word FireWire before? What would you write in the end-user documentation? Who would be using such option? I am afraid about the endless stream of why are you not making it the default?, like the one we already get regarding Javascript. Answers would probably be even quite similar. I'm not having such option, but it really needs to be done right. -- Ague pgp8l9z0LmDSa.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] tails-persistence-setup and feature coupling
Hi! While reflecting on the implementations of persistence of Network Manager connections and browser bookmarks, it occured to me that we might have an undesired coupling between tails-persistence-setup and our persistence framework as a whole. The implementation of persistent NM connections lead me to think that the pivot of our persistence framework is in `amnesia.git:config/chroot_local-includes/usr/local/sbin/live-persist`. Yet, both new persistence options required a change in another component, namely tails-persistence-setup to update `lib/Tails/Persistence/Configuration/Presets.pm`. I wonder if we should not move the content of Presets.pm to an 'external' file (from the point of view of tails-persistence-setup) which would live closer to `live-persist` instead. It could still be Perl code or transformed into YAML or another ad-hoc format. The trick is that it needs to be i18n'ed somehow... Any other opinions? (I don't think I'm fluent enough in Perl to propose any implementation, though.) -- Ague pgpHEBzpxqFrq.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails: pcmcia / firewire / etc.
On Fri, Oct 12, 2012 at 06:15:07PM -0700, Steve Weis wrote: Hi. I booted Tails' latest release and was able to scrape memory contents via FireWire. All the necessary firewire modules are enabled by default and Inception worked out of the box. This would let someone root a machine through, say, a daisy chained thunderbolt monitor. I'd either remove support from the kernel, blacklist the modules in modprobe, or disable support with a boot param. We can't just do that. Tails is also meant to be a safe environment to produce sensitive documents. Being able to retrieve a video from a DV camera, edit it and send it online is a use case Tails should support. From the recent discussions regarding ExpressCards and the likes, it looks like we are moving to a common pattern of you have 5 minutes to plug things on those ports that can be dangerous, otherwise, they will be disabled. This should work for FireWire too, even if it feels more cumbersome to me than for an expansion card. -- Ague pgp4q3EidLIt5.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Upstreaming yelp patch
On Sat, Oct 13, 2012 at 11:11:11AM +0200, intrigeri wrote: hi, Ague Mill wrote (12 Oct 2012 20:44:31 GMT) : On Fri, Oct 12, 2012 at 05:52:50PM +0200, intrigeri wrote: to anyone who pushed commit 64de544 (Fix Yelp crashing on internal links): [...] 2. Please open a ticket about upstreaming this fix. I don't see the need: [...] * Yelp has been heavily rewritten since Squeeze. I have not tested, but I doubt the bug is still in the version in Wheezy. If the bug was fixed upstream since then (== is not present in Wheezy), then I agree, the effort is not worth it, let's forget about it. My look at the code was right: everything is different. Except there is yet another bug in the code affecting internal links... See https://bugzilla.gnome.org/show_bug.cgi?id=686095 for details. That patch also applies to the version currently in Wheezy. -- Ague pgpEyEuSpWN1i.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Upstreaming yelp patch
On Fri, Oct 12, 2012 at 05:52:50PM +0200, intrigeri wrote: to anyone who pushed commit 64de544 (Fix Yelp crashing on internal links): 1. Congrats! 2. Please open a ticket about upstreaming this fix. I don't see the need: * GNOME documentation is not affected as far as I have seen, * Yelp has been heavily rewritten since Squeeze. I have not tested, but I doubt the bug is still in the version in Wheezy. What we could do is to try to push a fix in the next Debian Squeeze point release, but I don't think the bug is severe enough, as it does not show up when browsing GNOME documentation. I'd be happy to be convinced otherwise, though. -- Ague pgpjwC4XeDfuH.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Design doc update
On Fri, Oct 12, 2012 at 08:30:57PM +, Alan wrote: The following commit would require an update of the design doc, which I didn't find: commit 4be2ee47b30f851a0006c894214e84c8c71ea146 Author: Tails developers amne...@boum.org Date: Tue Oct 9 13:00:27 2012 +0200 Allow amnesia user to use Tor's TransPort. If you are its author, please update it or point me to the commits I didn't found (or state you won't do it and somebody else should volonteer). This is already documented in https://tails.boum.org/contribute/design/#index27h3: The Tor software is currently configured as a client only (onion proxy). The client listens [...] as a transparent proxy on port 9040 (only used for remapped hidden services) [...]. The aforementioned port is useless since 0.13 as no applications run by the main user (amnesia) is able to acces it. This commit fix a regression introduced when adding more restrictions for outgoing packets. -- Ague pgpIHcZRKZMVp.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review feature/hugetlb_mem_wipe
On Tue, Oct 09, 2012 at 04:17:45PM +0200, anonym wrote: I experimented with yet another approach to improve the situation of our memory wiping mechanism. Maybe all we needed to fix the current process was 0f1f476d, but well... [...] I've now benchmarked current devel vs. the feature/hugetlb_mem_wipe branch. I was done in a 64-bit VM with 8 GB of RAM. In each test I verified that the memory was completely filled with the pattern before wiping. Thanks _a lot_ for your benchmarks. Provided a little more feedback, this could go in 0.14. We can always revert if rc1 proves it deficient. Given that: * current devel cleans *all* memory in the most common case (PAE kernel), and that it does so without taking very much more time, and * I'm unsure what the implications are of hugetlb_mem_wipe exiting with that error on a non-PAE kernel, I'd rather wait with merging feature/hugetlb_mem_wipe until after Tails 0.14. I agree. It looks like `feature/hugetlb_mem_wipe` needs a little bit of polishing, at least on non-PAE kernels. It also looks like we could tune the parameters to clean up a little bit more memory. -- Ague pgppAo6BoATuk.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review feature/hugetlb_mem_wipe
On Tue, Oct 09, 2012 at 04:43:11PM +0200, intrigeri wrote: anonym wrote (09 Oct 2012 14:17:45 GMT) : * feature/hugetlb_mem_wipe: - With PAE kernel: * Patterns remaining after wipe: ~39K ≃ 600 KiB of memory * Time required for wipe: 2.5 seconds. - With normal non-PAE kernel: * Patterns remaining after wipe: 51K ≃ 800 KiB of memory. Also, in this case hugetlb_mem_wipe exits at 51% progress with the following error: [...] * Time required for wipe: ~1 second. This looks very promising! Ague, what are the advantages of this solution, compared to the fill a tmpfs idea you also had? (The latter would arguably have a simpler implementation, that most of us could understand and debug, contrary to the fancy hugetlb_mem_wipe one. Simplicity matters.) tmpfs currently does not use huge pages, so this is doomed to be slower. Also I was a bit disappointed by how the kernel currently handles out-of-memory with when using tmpfs: instead of erroring write(2) with ENOSPC, it simply kills the process. This makes it harder to implement a nice progress bar... But yeah, combination of dd, pv and a tmpfs should also be able to do a faire amount of wiping. hugetlb_mem_wipe is written in C, but it is fairly classic C/Unix code. The most delicate part is the call to mmap(2), but it is a matter of finding the right set of options. Huge pages are a fancy Linux feature, true, but I was able to find examples easily. To sum it up: hugetlb_mem_wipe is mostly done, is very likely to be faster than other solutions and has a nice progress bar. -- Ague pgpJGfZVotTNl.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Bookmarks persistence - help needed
On Fri, Oct 05, 2012 at 10:31:16PM +0100, Alessandro Grassi wrote: Instead of using the 'link' option of the persistence framework, how about using another directory, then? This would result in the following approach: * At build time: - create an Iceweasel profile, - create an empty `~/.mozilla/bookmarks` directory, - remove `places.sqlite` from the Iceweasel profile, - add a symlink `~/.mozilla/default/places.sqlite` pointing to `~/.mozilla/bookmarks/places.sqlite`. * When bookmarks persistence is activated: - add `~/.mozilla/bookmarks` to the set of persistent directories. Wanna try it? Looks a little tricky to me, but it works. Let's go this way! ;-) Great. :) All the needed patches are attached: 0001-generate-iceweasel-profile-at-build-time.patch and 0001-symlink-places.sqlite-for-bookmarks-persistence.patch are for Tails; This one should also create an empty directory in /etc/skel. Otherwise the 'bookmarks' directory will not exist when no persistence is used, resulting in a broken Iceweasel. What is also needed before we can merge this work is an update to the design documents and the end-user documentation, see https://tails.boum.org/contribute/merge_policy/ for details. Do you want to carry on your work on this front as well? Thanks for your contributions! -- Ague pgp6mnGZ1OKGM.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Bookmarks persistence - help needed
Hi Alessandro, On Fri, Oct 05, 2012 at 11:49:20AM +0100, Alessandro Grassi wrote: attached patch 0001-Added-bookmarks-preset.patch adds a Browser bookmarks preset in tails-persistence-setup. It creates a bookmarks folder in the persistent volume and links files from this folder to /home/amnesia/.mozilla/firefox/default. It needs the 0001-generate-iceweasel-profile-at-build-time.patch to be applied to Tails (see generate Iceweasel profile at build time discussion). I suggest you always send the full patch series for review. It's small enough it make sure there is no misunderstandings in which version of the previously sent patches should be used. The bookmarks folder is supposed to contain the places.sqlite file alone. If it's not there when preset is turned on, a default one should be copied (creating an empty file won't work). Having an empty file also did not work in my own tests. What worked was to have a `places.sqlite` that was a symlink. When it was pointing to a non-existent file, Iceweasel happily proceeded to create the file from the default settings. Instead of using the 'link' option of the persistence framework, how about using another directory, then? This would result in the following approach: * At build time: - create an Iceweasel profile, - create an empty `~/.mozilla/bookmarks` directory, - remove `places.sqlite` from the Iceweasel profile, - add a symlink `~/.mozilla/default/places.sqlite` pointing to `~/.mozilla/bookmarks/places.sqlite`. * When bookmarks persistence is activated: - add `~/.mozilla/bookmarks` to the set of persistent directories. Wanna try it? -- Ague pgpRRwAqKUfO2.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review feature/early_skip_unwanted_packages
On Sat, Sep 29, 2012 at 08:52:26PM +0200, intrigeri wrote: 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. Reviewed, tested, merged. :) (I have not done any measurements regarding build speed, though.) -- Ague pgpiknDGJbYU1.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review and merge feature/persistent_NM_connections [was: tails-persistence-setup releases vs. Tails 0.14]
On Wed, Oct 03, 2012 at 11:21:05PM +0200, intrigeri wrote: intrigeri wrote (03 Oct 2012 17:30:10 GMT) : anonym wrote (03 Oct 2012 14:34:59 GMT) : So, with the current state of things it still looks like a bug to me, although with nice side-effects. Making it into a proper feature (i.e. patching nm-applet) is definitely desirable, but not something I'm willing to take on for the 0.14 release. I'm now convinced. Let's document this as a known issue, and create a ticket to remember we need to make up our mind some day on this topic (possibly after Wheezy is released). I've tested the branch and I'll be happy to merge it once we have made a decision on the autoconnect thing (deadline for anonym's proposal: Friday at noon CEST). Don't wait for me, I am convinced as well. -- Ague pgp5LnkSh9Ila.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review and merge feature/persistent_NM_connections [was: tails-persistence-setup releases vs. Tails 0.14]
Since live-persist is the glue that fixes all the quirks we have with live-boot's vanilla persistence, this seems like a perfect fit. This is done in commits 77c3261 and 4db38e9. Looks nicer this way. The function `fix_gconf_dirs` might benefit from some more quoting of the variables. Maybe filesystem corruption could put a space somewhere bad... * Connect automatically checkbox gets unchecked on each boot: IMHO this bug is good :). Hence we can ignore this for now and just mention it as a known issue (commit 0f7f652). We have to rule this as either a bug or a feature. In my views, it is a feature and we just have to state it that way: Tails do not connect automatically to networks it was previously connected to. So I'd rather remove the addition to known issues, and document that behaviour better on `doc/first_steps/persistence/configure`. No tests done yet, but it looks good so far! :) -- Ague pgp8M6uoDVNAO.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Shipping a 686-pae kernel
On Sat, Sep 29, 2012 at 08:42:37PM +0200, intrigeri wrote: 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. I don't think they are neeeded anymore after the various improvements to the build system that was made. -- Ague pgpTHekbusrg1.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Shipping a 686-pae kernel
On Sat, Sep 29, 2012 at 05:50:05PM +0200, intrigeri wrote: 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. Done. Merged in experimental. My tests are still conclusive and I really think the branch should be reviewed one more time and merged in devel now. 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). If the bug is still reproducible in Wheezy, it has to be done. But I am really unsure on the best place to actually report the bug. Someone would probably have to come up with a smaller test case, too. -- Ague pgpJYgGbrgWHq.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review and merge bugfix/iceweasel_file_associations
On Sun, Sep 30, 2012 at 11:41:28PM +0200, intrigeri wrote: The bugfix/iceweasel_file_associations branch fixes that, candidate for Tails 0.14. Changes from stable to that branch: dccc7fa Start iceweasel from NM with the same XDG_DATA_DIRS settings as the GNOME session Thank you very much for getting to the bottom of this! I was cursing once more just yesterday when GIMP fired up when a wanted to view a PDF. :) I confirm the fix works. Merged in stable and devel! -- Ague pgp2qqqwmKBlm.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review feature/separate_Tor_streams
On Sun, Sep 30, 2012 at 03:46:57PM +0200, berta...@ptitcanardnoir.org wrote: Done the tests, works as expected, merged (with --no-ff this time) in devel, and pushed. Could you outline how you made those tests (e.g. tools, process)? -- Ague pgp28X8qWgMHB.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Faking htpdate user agent worth it?
On Mon, Oct 01, 2012 at 07:18:00AM +0200, intrigeri wrote: Since you are also using curl and only download the header, does faking the Tor Button user agent provide any additional benefit? Couldn't the server quite easily distinguish from real Tor Button users and tails_htp curl users? It may be worse than what you are suggesting. If iceweasel + Torbutton rarely, if ever, sends HTTP HEAD requests, then we should probably not pretend to be Torbutton. Does it? I think the overhead of not using '--head' and doing a full GET would be marginal. It would make it at least a little bit harder to distinguish from other requests. -- Ague pgp9rOIWyQjYl.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] [patch, please review] generate Iceweasel profile at build time
On Sun, Sep 30, 2012 at 04:18:07PM +0100, Alessandro Grassi wrote: People usually use Xvfb when they need a 'fake' X server. See the 'xvfb' package in Debian, and the `xvfb-run` script it contains. xvfb works fine, new patch is attached ;-) Great! The hook looks fine. Minor cosmetic remark: I'd rather have the profile named 'default' than 'amnesia'. The 'amnesia' name is a leftover from the very first versions of what became Tails. Maybe someday we'll want to get rid of those. Now the real thing: make bookmarks persistent. I got it working using dotfiles and putting places.sqlite in the right subfolder, so I can make a preset in tails-persistence-setup which links bookmarks/places.sqlite to /home/amnesia/.mozilla/firefox/profiles/amnesia/places.sqlite (I looked at the code). The only missing thing is the first-time behaviour: the existing places.sqlite (or, if missing, a default one) must be moved to the persistent storage and linked to the profile folder, and Iceweasel should not be open while this happens. Is there a way for tails-persistence-setup to execute a script on preset activation? I am not sure I understand. Do you already have code for that? Some tests have shown that you can have `places.sqlite` be a symlink to a file in another directory, e.g. `~/.mozilla/tails-bookmarks`. If the symlink points to a non-existent file, then Firefox will happily create it from the defaults when it starts. So I suspect that making this directory persistent would do the trick. -- Ague pgpVaRcdUOqj7.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review bugfix/default_search_engines
On Thu, Sep 27, 2012 at 10:27:34AM +0200, intrigeri wrote: Ague Mill wrote (26 Sep 2012 10:43:31 GMT) : Do you have any idea of how to do it better? The only one that comes up to my mind is that we move all search plugins somewhere else in the chroot tree and use a local hook to add links in directories corresponding to given the installed localization package set. It feels unnecessarily complicated. I agree it is a bit complicated, but I disagree on the unnecessarily part: I think it's the only way to fix this bug in a robust way, that is, to avoid seeing this bug re-appear, without us noticing, as soon as the list of iceweasel localization packages changes (e.g. if fr_BE appears, or if es_MX disappears). We don't want to test every language setting at release time for such regressions. Done. Have a look at commit d3ebdba5. f9d73a5 Be consistent when giving a locale to check.torproject.org OK, great. (FTR, the previous setting made sense when our syslinux menu allowed to pick Portuguese, and that's all -- considering there are many more Portuguese speakers in Brasil than in Portugal.) I have a feeling that this commit is too much or too little, and causes a tiny regression for Brasilian users -- while we're at it, we should add support for pt-BR in our branding extension. Yes, that'd be the way to go. Added to the branch, then (commit 5ba8642). That did not work without another changes (commit 966f639). -- Ague pgpY9dkqtH4hM.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Improvement of the shutdown sequence
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. Static review: fine with me, but now that we have merged feature/catch_errors_in_hooks, you want to add a set -e in config/chroot_local-hooks/52-update-rc.d. That's not much, but it still needs to be done and tested. Merging devel back took care of it. Initial test works fine, but I skipped the emergency shutdown test. That one will be for the next (hopefully final) iteration :) Emergency shutdown still works fine. -- Ague pgpggWXUgEPLw.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails webbrowser homepage
On Wed, Sep 26, 2012 at 07:44:48PM +0200, a...@boum.org wrote: So, we might want to use the Tails website as the iceweasel homepage, so that users know about it and find how to get in touch, report bugs, etc. (a bookmark to https://check.torproject.org/ has been added in the devel branch (commit 89d7561) to ease the transition). Another reason to switch homepage to something else (a light check.torproject.org version, perhaps?) is that [[the current one is not discreet enough|bugs/Congratulations_notice.]]. The Tails website is not substantially more discreet. 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. However, no decision have been reached now. Thoughts? I am still in favor of moveing to https://tails.boum.org/news/ or another compound page which would highlight a few recent news item and the documentation. -- Ague pgpA5CDTSGS2e.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Download manager
On Wed, Sep 26, 2012 at 07:44:20PM +0200, a...@boum.org wrote: https://tails.boum.org/todo/include_download_manager/ - As mentioned on the forum in [[/forum/using_DownThemAll___40__iceweasle_firefox_addon__41__]], 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. If so, [uget](http://urlget.sourceforge.net/) could be a good candidate. [[!tag todo/discuss]] uget is in Debian. I don't think such tool is needed in the default set of software. People can always install it through APT. We could include a default configuration that enables SOCKS proxying. I won't work on it though. -- Ague pgpqWRhlLaCoX.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails: pcmcia / firewire / etc.
On Wed, Sep 26, 2012 at 07:44:34PM +0200, a...@boum.org wrote: Issue: 32bit PCMCIA gets DMA. It is thus usable by an adversary for external bus memory forensics on a running Tails. Question: we now have to discuss what usability vs. security balance we want. Ideas: * 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 don't know how this would be possible without serious kernel hacking. * disable these buses by default, allow opt-in through tails-greeter to enable * 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 * 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 still prefer the later. -- Ague pgpi8mXnZmBpw.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Shipping a 686-pae kernel
On Thu, Sep 27, 2012 at 11:57:06AM +0200, intrigeri wrote: anonym wrote (27 Sep 2012 09:38:32 GMT) : This was in Tails built from feature/multikernel. Thank you. I updated the ticket accordingly. So, next step is: somehow fix our USB installer vs. the 686-pae kernel. I'm not committing to do it any time soon. After some gdb lifting, I got a stack trace mentioning `_dbus_watch_invalidate`. This lead me to find this pretty old blog post http://abandonedwig.info/blog/2009/03/dbus-and-threads.html mentioning that these stack traces were usually because of locking issues. It also mentions that asking DBus to properly handle multiple threads is as simple as running `dbus_thread_init_default()` http://dbus.freedesktop.org/doc/api/html/group__DBusThreads.html#ga33b6cf3b8f1e41bad5508f84758818a7 Unfortunately, while it looks fairly easy to do from Python when using GLib, according to the answers on this page http://stackoverflow.com/questions/6379553/calling-dbus-python-inside-a-thread, I have not been able to find a way to easily do something similar for the Python DBus Qt bindings. 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. 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. It's far from ideal, but it looks like there is very few users of the Python Qt DBus binding. And our installer is hackish already... which unfortunately tend to lead to more hacks. :( What's your opinion? Should I proceed in adding a custom `python-dbus` to the multikernel branch? -- Ague pgpiUejoin6pE.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review feature/separate_Tor_streams
On Mon, Sep 24, 2012 at 07:55:23PM +0200, intrigeri wrote: Please review feature/separate_Tor_streams. The bulk of the changes has been in experimental for a few weeks. Great work! I am happy to see how the implementation turns out. :) +++ b/config/chroot_local-includes/etc/iceweasel/pref/iceweasel.js +pref(network.security.ports.banned, 8118,8123,9050,9051,9061,9062,9063,9051); 9051 appears twice. +++ b/config/chroot_local-includes/etc/tor/tor-tsocks-mua.conf +# This is the configuration for libtsocks (transparent socks) for use +# with tor, which is providing a socks server on port 9050 by default. +server_port = 9061 The header is confusing. I think it should be more specific to the MUA case. +++ b/config/chroot_local-includes/usr/local/sbin/htpdate +[ 'proxy|p:s', what to pass to curl's --socks5-hostname ], According to its manpage, curl will use the following environment variable: `http_proxy`, `HTTPS_PROXY`, `FTP_PROXY`, `ALL_PROXY`. I wonder if it would not make the behaviour of htpdate more consistent to manually unset those variables before running `curl`. Otherwise, htpdate could use a proxy with '-p' specified on the command-line. I am not very strong on this, but this could lead to some (bad?) surprises. +++ b/wiki/src/contribute/design/Tor_enforcement/Network_filter.mdwn +[[!tails_gitweb config/chroot_local-includes/etc/firewall.conf]] This needs to be updated now that we are using ferm. +++ b/wiki/src/contribute/design/stream_isolation.mdwn I think this page deserve a link to proposal 171: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/171-separate-streams.txt +Applications are configured to use the right SOCKS port: I have a tickling feeling that this list will get outdated... No tests done so far. This one deserve to be looked at closely. Uh... and actually, those changes might require to add some more tests to the checklist. What do you think? -- Ague pgpdKE4t2bi5e.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review bugfix/default_search_engines
On Wed, Sep 26, 2012 at 12:22:30PM +0200, intrigeri wrote: Ague Mill wrote (25 Sep 2012 22:06:33 GMT) : The branch bugfix/default_search_engines fixes the default search engine selected for Portugese and Spanish. Great! Short log: 46a7885 Fix localized search plugins for 'es' and 'pt' I quite dislike the file duplication. Can't the copying be done in a chroot_local-hook? Also, by reading the commit message, it's unclear why only these specific locales are supported, instead of all Spanish-speaking and Portuguese-speaking countries. I think there are something like two dozens countries that speak mainly Spanish, rather than 4. So, perhaps the file copying should happen quite more heavily (one more reason to automate it :) These directories match Iceweasel localization packages. For 'es': * iceweasel-l10n-es-ar * iceweasel-l10n-es-cl * iceweasel-l10n-es-es * iceweasel-l10n-es-mx For 'pt': * iceweasel-l10n-pt-br * iceweasel-l10n-pt-pt Do you have any idea of how to do it better? The only one that comes up to my mind is that we move all search plugins somewhere else in the chroot tree and use a local hook to add links in directories corresponding to given the installed localization package set. It feels unnecessarily complicated. f9d73a5 Be consistent when giving a locale to check.torproject.org OK, great. (FTR, the previous setting made sense when our syslinux menu allowed to pick Portuguese, and that's all -- considering there are many more Portuguese speakers in Brasil than in Portugal.) I have a feeling that this commit is too much or too little, and causes a tiny regression for Brasilian users -- while we're at it, we should add support for pt-BR in our branding extension. Yes, that'd be the way to go. -- Ague pgpT28P71ZLwX.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review feature/separate_Tor_streams
On Wed, Sep 26, 2012 at 01:54:51PM +0200, intrigeri wrote: +++ b/config/chroot_local-includes/usr/local/sbin/htpdate +[ 'proxy|p:s', what to pass to curl's --socks5-hostname ], According to its manpage, curl will use the following environment variable: `http_proxy`, `HTTPS_PROXY`, `FTP_PROXY`, `ALL_PROXY`. I wonder if it would not make the behaviour of htpdate more consistent to manually unset those variables before running `curl`. Otherwise, htpdate could use a proxy with '-p' specified on the command-line. Consistent with what? All this paragraph of yours is very unclear to me, and I'm not sure what you mean. Please rephrase, e.g. point out a specific potential problem you are envisioning :) htpdate lists a --proxy option. I may assume that when I don't specify this option, it will not use a proxy at all. But, the current code will still use a proxy if HTTPS_PROXY or ALL_PROXY are set. I think this is confusing. I have a tickling feeling that this list will get outdated... Are talking of the list (of links to configuration files) that follows the introduction sentence you are quoting, or what? If you are, well, right, but this is a general problem with our entire design document. That would be partly addressed by a check for broken links, and additional strictness on the design doc front when reviewing/merging branch. Yes, I was talking of the links to the configuration files. But yes, I don't have a better idea. Uh... and actually, those changes might require to add some more tests to the checklist. What do you think? I'll think of it later today or tomorrow. Neat! :) -- Ague pgpuorTb3rIBh.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Next release: process, schedule and iceweasel backports
On Wed, Sep 26, 2012 at 03:10:36PM +0200, anonym wrote: To end with, given the amount of nice stuff we're currently merging into devel, I'd be sad to see this wait until December before being shipped to users, and I'm starting to wonder if we should not make the next release a major one. That could be Tails 0.14. How crazy does that sound? Not crazy at all. I'm all in for a major release. I'd really like it to include feature/multikernel, something that looks fairly doable. *If* we indeed choose to do this I suppose that would push the Tails 0.14 freeze date to the next Firefox ESR release date, which is October 9th (essentially two weeks from now), so: October 9th: 0.14 freeze + release of RC1. October 23th: ESR backport is (hopefully) available. October 25th: release of RC2. October 30th: release of 0.14. Fine with me. -- Ague pgpH7K9X1VIb7.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Block/unblock wireless devices?
On Mon, Sep 24, 2012 at 10:42:51PM +0200, intrigeri wrote: at boot time, Liberté Linux now explicitly unblocks Wi-Fi, WWAN and WiMAX, and soft-blocks all other kind of wireless devices (Bluetooth, UWB, GPS, FM). This is implemented using rfkill. This may prevent some unwanted leaks through the wireless devices that are unlikely to be useful in the context of Tails, and at the same time, improve the user experience with wireless devices that come up in blocked state after boot. I think we should do this in Tails, and write a short documentation page about how to manually unblock a blocked (e.g. GPS) device when needed (e.g. sudo rfkill unblock gps). Thoughts? Bluetooth can be problematic. Some systems use Bluetooth to communicate with their keyboards and mouses. AFAIU, that is one of the reason why most Bluetooth enabled systems will always powerup the radio during first stage of the boot process, so one with a Bluetooth keyboard can reach firmware settings. I was thinking something like yeah, we could have a checkbox in the greeter, but many laptops have an hardware kill switch these days. In any cases, blocking GPS by default sounds like a good plan. -- Ague pgptLmhPoFhEX.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] [patch, please review] generate Iceweasel profile at build time
On Mon, Sep 24, 2012 at 05:24:51PM +0100, Alessandro Grassi wrote: How far have you tested this patch? Does calling `iceweasel -CreateProfile` requires to have an X server running? I didn't test this. Turns out that it requires an X server! Thanks for asking! We need to work around this somehow. People usually use Xvfb when they need a 'fake' X server. See the 'xvfb' package in Debian, and the `xvfb-run` script it contains. Overall, I am still having a hard time convincing myself that generating an Iceweasel profile on build time is the way to go. That is why I have been researching how complicated it would be to create a dedicated extension... But I am happy to see you trying this approach. We will be able to see how far it goes! :) Also, it would be better if the hook would start with `set -e` in order to catch any errors that can happen in the process. How do I do that? I just put `set -e` before other commands? Yes, just put it at the start of the script. For what it does, let's quote dash(1): If not interactive, exit immediately if any untested command fails. The exit status of a com‐ mand is considered to be explicitly tested if the command is used to control an if, elif, while, or until; or if the command is the left hand operand of an “” or “||” operator. -- Ague pgpYUyniA26sA.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please merge feature/Tor_0.2.3
On Mon, Sep 24, 2012 at 05:31:26PM +0200, intrigeri wrote: please review and merge feature/Tor_0.2.3 It has been in experimental for a while, I've just sync'd it against current devel and re-tested, candidate for Tails 0.14. Reviewed, merged in devel. Maybe 0.2.3 will even be declared stable before 0.14 is out. Who knows? :) -- Ague pgpYKxGIGBMui.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review feature/use_ferm
On Mon, Sep 24, 2012 at 03:56:05PM +0200, berta...@ptitcanardnoir.org wrote: I'm not too happy with the initial commit (f00effb), because it removes the check for the needed tool existence and leaves the exit code checking to the implicit. Fixed in devel. I suggest: * re-adding something like: [ -x /usr/sbin/ferm ] || exit 2 * clarifying with a comment that the ferm command invocation should remain the last one in this script. I went with the `set -e` way instead of that last one. About ferm.conf, the Emacs mode line sets shell-script, but given the syntax, apparently conf-space-mode or perl-mode do a quite better job, so I suggest: # -*- mode: conf[space] -*- Done in devel. -- Ague pgpIoqnxf2CJT.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Improvement of the shutdown sequence
Hi! I spent some more time working on initscripts and the shutdown sequence. On Tue, Jun 05, 2012 at 06:11:45PM +0200, intrigeri wrote: I'm slowly starting to seriously prefer the patch initscripts' LSB headers with chroot_local-patches/ approach. Although less elegant, I think it would be more robust and cheap maintenance wise: we would be told at (failed) *build* time when something has changed in the context of the lines we're patching. Pretty convincing argument. :) I'd be happy to get reviews of what is in feature/shutdown_cleanup. It has been rebased against latest devel and it now uses patches insead of insserv overrides. Short log: e9c2c4f Prevent memlockd unload on shutdown f8b5dff Fix tails-sdmem-on-media-removal initscript header 93dd8b3 Leave halt and reboot scripts configured These first three commits should probably be considered as bugfixes. ccf5a60 Assert that dependency based boot sequencing is configured dd53671 Disable i2p initscript rather than remove it 32cbde7 Patch initscripts headers instead of fiddling with update-rc.d These makes `chroot_local-hooks/52-update-rc.d` way nicer and less error prone. fea2ad6 Do not run unecessary scripts during shutdown sequence This last one allows to win 7-9% of total shutdown time on my test system (compared to 0.13). -- Ague pgpuGWRFzg8cI.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Using the http.debian.net redirector?
On Fri, Sep 21, 2012 at 09:59:15PM +0200, intrigeri wrote: it looks like the http.debian.net redirector looks mature enough to be worth considering using it as the default APT repository in Tails images. It supports the main archive, as well as backports. Rationale: * constantly use an APT mirror that's close from the exit node being used I did some tests, with the same pros in my mind. But it seemed to me that it was plagued by similar problems than 'cdn.debian.net': sometimes, one circuit is created and goes to one mirror, and the one just after goes to a different mirror. And one of those mirrors is more up-to-date than the other, resulting in APT complaining about missing files or mismatching checksums. But that was just over an afternoon before switching back to ftp.us.debian.org. I'll be happy to hear other experiences. -- Ague pgppNfTJr0e5r.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review bugfix/fix_background_readahead
On Sat, Sep 01, 2012 at 12:26:51PM +, Ague Mill wrote: On Sat, Sep 01, 2012 at 01:52:04PM +0200, berta...@ptitcanardnoir.org wrote: On Sat, Sep 01, 2012 at 11:02:22AM +, Ague Mill wrote: On Sat, Sep 01, 2012 at 12:35:27PM +0200, berta...@ptitcanardnoir.org wrote: Also I haven't found a corresponding ticket in the wiki, appart from the old todo/improve_boot_time_on_cd, which is marked as done. What should be written in there? Like you described in your previous mail I guess, something like Since 0.12, a regression was introduced in the readahead mechanism that makes the bloot slower because it pauses (rephrase this lame words as you want). Done: https://tails.boum.org/todo/fix_background_readahead/ Can someone else test the changes, now? :) I am coming back with this. It would be good if someone else could test these changes. -- Ague pgpXp7DxeseCq.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tor 0.2.2.x package in 0.13
On Thu, Sep 13, 2012 at 12:39:33PM +0200, intrigeri wrote: I think we need to ship Tor 0.2.2.39 in Tails 0.13, but apparently weasel only pushes updated packages of 0.2.2.x to stable-proposed-updates these days, and this has not been done for 0.2.2.38-39 yet. Therefore, I think we should build our own binary packages from weasel's debian-tor-0.2.2.39-1 Git tag. I can do that. Thoughts? Please proceed. :) -- Ague pgpXUNQkCqTtS.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review bugfix/fix_background_readahead
On Sun, Sep 02, 2012 at 02:37:24PM +, Ague Mill wrote:
On Sun, Sep 02, 2012 at 03:28:36PM +0200, intrigeri wrote:
Ague Mill wrote (01 Sep 2012 12:26:51 GMT) :
Can someone else test the changes, now? :)
:)
I'm unlikely to do it any time soon on bare metal,
but it might help it that work was merged into experimental.
Given it's a candidate for 0.13, I think it's not the best branch to
test it, but I've done the merge nonetheless.
I still understand what could it make worse than the current situation,
but given that:
anonym I'd like to see that live in experimental for a while before
I trust it :)
ague Should I write another patch that remove the offending 'cat'
that is not running in the background?
intrigeri I think I would happily merge that one.
See attachment.
--
Ague
From 1c0883518de62c30b1aee8e40e706b39013806ec Mon Sep 17 00:00:00 2001
From: Tails developers amne...@boum.org
Date: Mon, 3 Sep 2012 17:44:09 +
Subject: [PATCH] Stop readahead pretending that it can read file in the background
Files are not read in the background. This means we have a noticable pause
without any progress bar. This just slow the boot process, so let's stop
reading those extra files.
---
.../lib/live/config/-readahead |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/config/chroot_local-includes/lib/live/config/-readahead b/config/chroot_local-includes/lib/live/config/-readahead
index c29edbd..fdaecf9 100755
--- a/config/chroot_local-includes/lib/live/config/-readahead
+++ b/config/chroot_local-includes/lib/live/config/-readahead
@@ -25,21 +25,15 @@ Readahead ()
Start_readahead ()
{
FG_FILES=$(sed -n \:$BACKGROUND_AT:q;p $READAHEAD_LIST)
- BG_FILES=$(sed -n \:$BACKGROUND_AT:,\$p $READAHEAD_LIST)
FG_SIZE=$(
cd /
echo $FG_FILES |
xargs du -c 2/dev/null |
awk '$2 ~ /^total$/ { t = t + $1 } END { print t }')
(cd /
- echo $BG_FILES |
- xargs stat /dev/null 2/dev/null || :)
- (cd /
echo $FG_FILES |
xargs cat 2/dev/null |
pv -f -s ${FG_SIZE}k /dev/null || :)
- (cd /
- echo $BG_FILES | xargs cat /dev/null 21 || :)
# Creating state file
touch /var/lib/live/config/readahead
--
1.7.2.5
pgpZop5bOKjO9.pgp
Description: PGP signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review bugfix/fix_background_readahead
On Mon, Sep 03, 2012 at 05:48:10PM +, Ague Mill wrote: On Sun, Sep 02, 2012 at 02:37:24PM +, Ague Mill wrote: On Sun, Sep 02, 2012 at 03:28:36PM +0200, intrigeri wrote: Ague Mill wrote (01 Sep 2012 12:26:51 GMT) : Can someone else test the changes, now? :) :) I'm unlikely to do it any time soon on bare metal, but it might help it that work was merged into experimental. Given it's a candidate for 0.13, I think it's not the best branch to test it, but I've done the merge nonetheless. I still understand what could it make worse than the current situation, ^ don't *sigh* -- Ague pgpzdF0Kd45x8.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review bugfix/fix_background_readahead
On Sun, Sep 02, 2012 at 03:28:36PM +0200, intrigeri wrote: Ague Mill wrote (01 Sep 2012 12:26:51 GMT) : Can someone else test the changes, now? :) :) I'm unlikely to do it any time soon on bare metal, but it might help it that work was merged into experimental. Given it's a candidate for 0.13, I think it's not the best branch to test it, but I've done the merge nonetheless. -- Ague pgpeH3vq1eR0H.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] When should we fix regressions?
On Sat, Sep 01, 2012 at 12:35:27PM +0200, berta...@ptitcanardnoir.org wrote: I still would like to see this reach 0.13~rc2. Given we're supposed to be freezed, I'm not sure this is a good idea, unless there is has been tested a lot before being merged, and there is a strong commitment to test this in the 0.13~rc2. Is the goodness of this patch worth the effort or risk to include this so lately in the release process? Ok. Maybe this should had been discussed some more. The process I know the best about time-based releases is the Linux kernel. What happens there is that there is a window of time where new features get merged in. When this window is closed, a first release candidate is made. Then, what goes in are fixes for bugs and regressions. Then a second release candidate is made, followed by more bug fixes. Repeat until kernel is deemed stable enough for a release. This delay on boot is a regression (which appeared in 0.12, IIRC). I don't see why it should not be fixed as soon as possible. There is a second release candidate planed. If it appears to cause problem, then it can be reverted before the final image. -- Ague pgpaPHZoeS0KS.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review bugfix/fix_background_readahead
On Sat, Sep 01, 2012 at 12:35:27PM +0200, berta...@ptitcanardnoir.org wrote: Also I haven't found a corresponding ticket in the wiki, appart from the old todo/improve_boot_time_on_cd, which is marked as done. What should be written in there? -- Ague pgpYBXWDDArQE.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review bugfix/fix_background_readahead
On Sat, Sep 01, 2012 at 01:52:04PM +0200, berta...@ptitcanardnoir.org wrote: On Sat, Sep 01, 2012 at 11:02:22AM +, Ague Mill wrote: On Sat, Sep 01, 2012 at 12:35:27PM +0200, berta...@ptitcanardnoir.org wrote: Also I haven't found a corresponding ticket in the wiki, appart from the old todo/improve_boot_time_on_cd, which is marked as done. What should be written in there? Like you described in your previous mail I guess, something like Since 0.12, a regression was introduced in the readahead mechanism that makes the bloot slower because it pauses (rephrase this lame words as you want). Done: https://tails.boum.org/todo/fix_background_readahead/ Can someone else test the changes, now? :) -- Ague pgpbNP0bhYr8p.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review bugfix/fix_background_readahead
On Mon, Aug 27, 2012 at 12:51:04AM +0200, intrigeri wrote: As you know, I tend to think the problem fixed by this patch is not worth the risks involved at this stage of the release process, but my extra-carefulness does not extend to vetoing if there is a general agreement with applying this patch before rc2. +start-stop-daemon \ + --start --background --pid /var/run/background-readahead.pid --startas /bin/sh -- \ + -c $BG_FILES | xargs cat /dev/null 21) I assume you wanted to write --pidfile, as --pid does not exist in my copy of start-stop-daemon. Beware before s/pid/pidfile/, though: given --pidfile presence/absence changes quite drastically the behavior of start-stop-daemon, if the proposed patch works, then this option is probably not needed, is it? Actually, this works due to GNU getopt magic: $ /sbin/start-stop-daemon --start --background --pidfile /tmp/test.pid \ --startas /bin/sh -- -c 'date /tmp/test' $ /sbin/start-stop-daemon --start --background --pid /tmp/test.pid \ --startas /bin/sh -- -c 'date /tmp/test' $ /sbin/start-stop-daemon --start --background --pi /tmp/test.pid \ --startas /bin/sh -- -c 'date /tmp/test' This fails: $ /sbin/start-stop-daemon --start --background --p /tmp/test.pid \ --startas /bin/sh -- -c 'date /tmp/test' /sbin/start-stop-daemon: option '--p' is ambiguous Getting rid of `--pidfile` also fails: $ /sbin/start-stop-daemon --start --background \ --startas /bin/sh -- -c 'date /tmp/test' /sbin/start-stop-daemon: need at least one of --exec, --pidfile, --user or --name What this made me realize, though, is that `--pidfile` is useless without `--make-pidfile` in this context. So I have updated the branch to fully spell `--pidfile` and to also create that pid file. The broken sed invocation was also fixed, and as added bonus, the foreground progress bar now goes to 100%. I still would like to see this reach 0.13~rc2. -- Ague pgpj8VCTGedWq.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Upcoming release schedule plan
On Sat, Aug 25, 2012 at 03:01:51PM +0200, berta...@ptitcanardnoir.org wrote: Following our discussions on the timeline for the next release, here is the plan we ended up with and I committed to send on this list : - Theoritically: ESR (August 28th) + 1 week = September 4th - August 23: release 0.13~rc1, do the test suite together Insert a call for translation updates. - Week 35 - Mon 27th: ESR is out update of the GnuPG docs - Week 36 - Tue 4th: release 0.13~rc2, testing phase Insert a call for translation quality assurance and minor fixes. - Thu 6th: monthly meeting - Week 37 - Tue 11th: release 0.13 (final) Please remember that the test suite needs to be done before pushing the final image. -- Ague pgpFQQD9e93Ho.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Disabling 'PC speaker'?
Hi! 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.) -- Ague pgpKshTkE8nkz.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please test 0.13-rc1
# Iceweasel * Browsing (by IP) a FTP server on the LAN should be possible. OK: FTP is reachable and usable. # Use of untrusted partitions * are any local hard-disk partitions mounted or used as swap? boot on a (possibly virtual) machine that has a cleartext swap partition not managed by LVM. This swap partition must not be used by Tails. * is a Live system found on a local hard-disk partition used? boot the DVD/USB stick you are testing on a (possibly virtual) machine that has a Tails system copied on a cleartext partition not managed by LVM. The DVD/USB ramdisk must use the Tails system found on the DVD/USB, and not the one found on the hard disk. (Also check that without Tails, that other Live system boots.) # Claws * Also check that the EHLO/HELO SMTP message is not leaking anything with a packet sniffer: start Claws using the panel icon (which runs `torify claws-mail`) to avoid using the transparent proxy (which will confuse tcpdump). Disable SSL/TLS for SMTP in Claws (so take precautions for not leaking your password in plaintext by either changing it temporarily or using a disposable account). Then run `sudo tcpdump -i lo -w dump` to capture the packets before Tor encrypts it, and check the dump for the HELO/EHLO message and verify that it only contains `localhost`. OK: HELO is 'localhost'. (I have tested by using 'nc -l -p 25 127.0.0.1' and manually acting like a SMTP server.) # Whisperback * can a bug report e-mail be sent? * is it correctly encrypted? Still doesn't work. # Monkeysphere * Monkeysphere validation agent key search/receive: torified? uses configured keyserver? # erase memory on shutdown - check that `memlockd` and `udev-watchdog` are running, and that the right device is being watched by the later. - remove Tails' media (USB and cdrom) and check that the memory erasure process is started (`Loading new kernel`, at least). Testing that the needed files are really mapped in memory, and the erasing process actually works, involves slightly more complicated steps that are worth [[a dedicated page|test/erase_memory_on_shutdown]]. # Persistence * Activate persistence on a Tails USB install with all presets on. * Reboot, enable persistence. Verify via `mount` that each preset has a mount that seem correct (e.g. Pidgin preset = `/home/amnesia/.purple` has something mounted on it). * Try read-write mode. Make sure that persistent files are writeable, and that changes do survive reboot. * Try read-only mode. Make sure that persistent files are writeable, but that no changes survive reboot. * Test adding a few custom directories. * Turn off some persistence presets, reboot, and make sure they are not activated. # Misc * Check that there are no weird applications listening to external connections with `sudo netstat -ltupn` (everything should be `127.0.0.1` (IPv4) or `::1` (IPv6)). OK: no weird applications to be seen. * Check that links to the online website (`Mirror:`) at the bottom of bundled static web pages are working. Else, it probably means the wiki was not built with the needed patched ikiwiki version. OK: links to the online website present. * Check that all seems well during init (mostly that all services start without errors), and that dmesg seems ok. OK. * Boot without network connection, and then plug it in after some arbitrary time; Tor and Vidalia must be autostarted and end up in working state. OK. * Doing an apt-get update and installing random packages. OK: tested with 'sl' and 'unsort' packages. * Boot on bare-metal on USB. OK. * Boot and check basic functionality is working for every supported language. - The chosen keyboard layout must be applied. - The virtual keyboard must work and be auto-configured to use the same keyboard layout as the X session. - The iceweasel search engine must be localized (for languages we ship a localized searchplugin for). OK: tested german, french, spanish, italian, portugese, vietnamese, russian, arabic, farsi, chinese. Default search engine for spanish and portugese is Google. Added to 'known issues'. * Try to start with the `truecrypt` option on boot, see if it can be found in the *Applications* → *Accessories* menu and that it runs correctly. OK: successfully created a encrypted container and mounted it. * Connecting over SSH to a server on the Internet should work (and appear in Vidalia's connections list). OK: connection successful. * Connecting (by IP) over SSH to a server on the LAN should work. OK: connection successful. * The `amnesia` user must be part of the following groups: `audio cdrom dialout floppy video plugdev netdev fuse debian-tor scanner lp lpadmin vboxsf` OK: `amnesia` is part of all those groups. * Measure boot time on some reference bare metal hardware, and compare with previous version. The new
Re: [Tails-dev] Please review bugfix/hide_TailsData_volume
On Sun, Aug 19, 2012 at 12:26:57AM +0200, intrigeri wrote: a...@boum.org wrote (18 Aug 2012 20:05:00 GMT) : Please review bugfix/hide_TailsData_volume which is supposed to fix: https://tails.boum.org/todo/persistence:_hide_or_fix_TailsData_volume Tested, merged, congrats! Actually, this will hide *any* partition that is labeled TailsData. What if I am using Tails to look the content of the persistent partition of another Tails USB stick (e.g. to fix issues or make backups)? A proper fix that is coming to my mind is to add a similar udev rule when the persistence is activated, matching the (known) UUID of the partition and not its label. -- Ague pgpJxYA6V5CDI.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] incremental upgrades: phase one almost done, release plan
On Tue, Jul 24, 2012 at 04:38:15AM +0200, intrigeri wrote: 1. As soon as possible, merge into devel the harmless part of the feature/incremental-upgrades branch (users creation with sudo credentials, dependencies installation), leaving aside the part about running the update frontend automatically at startup. = Tails 0.13 should be able to incrementally upgrade to 0.13.x Done. -- Ague pgpZKLCjKmRWt.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails Website Hack
Another email to the devs, although at a different email address. If you didn't recieve the last one, check the forums. I think the website has been hacked. One of our mirrors was badly configured for some hours. No hacks and the issue is fixed. See also: https://tails.boum.org/forum/Tails_Website_Hacked_-_WARNING/#comment-b1492295a776ae467640a69d3ef5e19d -- Ague pgpWPaQtOvoNF.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] CheckIt no longer available
On Sat, Aug 04, 2012 at 12:17:03PM +0200, sajolida wrote: I found a workaround for most cases but I wanted your opinion before putting that in the documentation. 1. Download the ISO 2. Install MD5 Reborned Hasher, restart Firefox 3. Open the ISO image from File ▸ Open File… and save it on top of itself. That's the weird move. It seems to work ok on Windows XP but it was not working on my machine where /tmp didn't have enough space to store a temporary copy of the full ISO. 4. Check the SHA-256 from the Download window. What do you think? I think it is better than nothing or unusable documentation. I'd say go for it. Ok, I fixed the documentation accordingly. Please review: https://tails.boum.org/doc/get/verify_the_iso_image_using_other_operating_systems/ I only read it (no tests), but it looked clear and easy enough. We'll see how our users feel about it. Good work! :) -- Ague pgpZfL4UatO2i.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] CheckIt no longer available
On Wed, Aug 01, 2012 at 05:28:49PM +0200, sajolida wrote: As pointed out by a user on the forum [1], the CheckIt add-on is not available anymore. Do you know why? I found a workaround for most cases but I wanted your opinion before putting that in the documentation. 1. Download the ISO 2. Install MD5 Reborned Hasher, restart Firefox 3. Open the ISO image from File ▸ Open File… and save it on top of itself. That's the weird move. It seems to work ok on Windows XP but it was not working on my machine where /tmp didn't have enough space to store a temporary copy of the full ISO. 4. Check the SHA-256 from the Download window. What do you think? I think it is better than nothing or unusable documentation. I'd say go for it. -- Ague pgpBuoxXYjPEn.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Can't achieve buildin tails Live CD
On Tue, Jul 24, 2012 at 03:31:42PM +0100, Nicolas B wrote: Here is my message in a bottle. I would like to build a Live CD of tails 0.12.1 on my own. But I have followed instructions from https://tails.boum.org/contribute/build/ without any result. Glad to know that you have tried to build your own Tails. Unfortunately, you did so at a time where two things where broken: multiarch plymouth has migrated to testing, and the custom ikiwiki repository was inacessible. The issue is fixed in both devel and experimental branches. devel is really close to 0.12.1, so I suggest you try to build it instead. Her is a sum up of my tries: Where each time I used the most recent components without tweeking in apt sources. And I used the 0.12.1 tag from the git repo to match the latest release version. - Debian 6.0.5 i386 VM - I got a Live CD but stayed locked to greeter, can't access the gnome desktop. It loops when I click on the Login button This one is weird. The other issues (plymouth at least) should not have left the build to finish. - Debian wheezy amd64 in a VM using manual build - got broken package when building dist Fixed in devel and experimental. Debian wheezy amd64 on a physical machine using valgrant - need tweaking to build ikiwiki Fixed in devel and experimental. Have fun, -- Ague pgpKcPCTxWXlJ.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] No need for a patched ikiwiki anymore
On Sat, Jun 30, 2012 at 12:57:13AM +0200, intrigeri wrote: [master 0f79c1e] No need for a patched ikiwiki anymore: ikiwiki 3.20120629 has everything we need :) I guess some Vagrant clevery should be updated accordingly. Done in devel and experimental branches. -- Ague pgpGGDzvNCBzW.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Installing unrar-free again?
On Thu, Jul 12, 2012 at 04:31:00PM -0600, intrigeri wrote: I did some testing and proposed that we ship unrar-free again, until we can install a version of file-roller that supports unar. What do you think? Archive Manager will fail for some RAR archives and not others. But probably we can have it that way until upstream releases the version supporting `unar` (and we get that in Debian). -- Ague pgpsBaC2H6YRV.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Include gdm logs in whisperback
On Thu, Jul 12, 2012 at 05:50:01PM +0200, a...@boum.org wrote: During debugging of Tails 0.12 boot issues, it appeared that it wolud be very useful for debugging such issues to have GDM logs included in bug reports. Candidates seems to be both stuff in /var/log/gdm3 and /var/lib/gdm3. I just had a look at this, and got several points to clarify. 1) what to include? - /var/log/gdm3 contains three files: - :0-slave.log: useful, contains session and postlogin scripts output - :0-greeter.log: tails-greeter log. Might be useful but contains tons of shit. If we want to include it, then we proably want to teach t-g to be less verbose (should be easy to do as it uses python logging facility). - :0.log: useless (I think), gdm's X server log - /var/lib/gdm3 doesn't contain logs but configuration snippets written by t-g. This one might include passwords that we would have to clean. Do we really want to include the options selected by the user? So just get :0-slave.log and :0-greeter.log for now. We'll see if that's enough or not. 2) How to include them? /var/log/gdm3 belongs to root:Debian-gdm with mode 1770. [...] Thus, I see several possibilities: - have an helper (GDM postlogin script?) chmoding /var/log/gdm3. Seems me not that nice; - have an helper (GDM postlogin script?) copying the logs we want to another location; - other ideas? Make mail_appended_info() call a (fairly trivial) script through sudo that would output all needed information. That script can be run as root and have access to all log files. It could actually replace most of what that function does. -- Ague pgpNxQFX6ZlEQ.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review and merge feature/precompiled-locales
On Thu, Jul 05, 2012 at 11:15:29PM +0200, intrigeri wrote: ticket: https://tails.boum.org/todo/ship_precompiled_locale_data Git branch: feature/precompiled-locales Merged into experimental. I don't really understand the choice of generating `/var/lib/gdm3/language_codes` in a live-build hook. Is there any reason why it can't be generated during tails-greeter build? It could then be shipped in a more policy compliant place than `/var/lib` (it is static data, after all, and only consumed by tails-greeter AFAIU). Other than that, the changes look fairly straightforwards. Have you made any tests? Did you notice a decrease in login time? -- Ague pgpY15oLSH7wy.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails Vagrant VM: repositories in /etc/apt/sources.list use http instead of https
On Mon, Jul 09, 2012 at 09:10:59PM +0200, Andreas Kuckartz wrote: Thanks for the suggestion to use vagrant ssh. I am now having a close look at the VM from inside. I noticed that all the repositories configured in /etc/apt/sources.list use http instead of https. I suggest to change that to reduce the threat of MITM attacks. To do that apt-get install apt-transport-https is required. All repositories and their respective content are authenticated using cryptographic signatures [1]. I don't really see a reason in preventing content proxying (which is essential for fast builds) to prevent DoS attacks. [1] http://wiki.debian.org/SecureApt I am experimenting with these and other changes. Please do! And submit patches! :) -- Ague pgpLZjGEXI4kC.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] [urgent] Tails 0.12 test results (we've got a potential blocker)
On Wed, Jun 13, 2012 at 08:03:46PM +0300, Maxim Kammerer wrote: On Wed, Jun 13, 2012 at 4:46 PM, anonym ano...@lavabit.com wrote: Yup. I've opened bugs/claws_with_torsocks_leaks_hostname to track this issue. This is possibly not a bug with torsocks, but a result of its extended functionality. [...] Thanks for your detailed analysis. :) -- Ague pgp7lBjnqMj0y.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Removing SSL CA dependency for HTP
On Fri, Jun 08, 2012 at 08:11:31PM +0200, pro...@secure-mail.biz wrote: intrigeri intrig...@boum.org wrote: I don't believe trust is a binary on/off thing. It's not because entity A trusts entity B for X, that it's safe and reasonable for entity A to rely on entity B for more and more things other than X. E.g. I would not find it a good idea if the Tor project started a free email hosting service. And I'm pretty sure they would not, with good reasons. Valid point. Conclusion, if we are going for hidden services, we need more hidden services. What makes you think it's harder to impersonate a Tor hidden service than a SSL CA shipped by Debian? Is it that hard to generate a HS key with the same 80-bits fingerprint than an existing one? SSL CA's: - relies on humans doing their job - has theoretical flaws - has practically been broken, recently! Hidden services: - relies on technology, distributed trust - has theoretical flaws - were never impersonated, until now. That's why my bet is on the hidden services horse. If hidden services get impersonated in the future, torproject will adapt and fix the issue. On the other hand, I don't expect the SSL CA issue to be resolved anytime soon. I have not done thorough research, but reading the design page again made me stare at this paragraph for a while: If using a bridge: your bridge can replay an old (one week old max.) consensus, which is used until HTP has fixed the time; not good, but probably a compromise we can make. If your bridge also can setup a SSL MitM attack against the HTP connections (e.g. the attacker also controls a SSL CA shipped by Debian), it can trick you into using this old consensus for max. one week, which is much worse. Does Tor ensure that the .onion address match the hidden service it reaches? I am not well versed enough in Tor internals to assert that. Otherwise, it looks like switching to hidden services would open a new class of attack for bridge users. I'd like to also say that I feel a bit uneasy with changing how our current time synchronisation system works. It took several releases before we got it right and it have not seen any problems being reported for a while… -- Ague pgpDdiU0LDHnh.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] [urgent] Tails 0.12 test results (we've got a potential blocker)
On Tue, Jun 12, 2012 at 07:21:36PM +0200, anonym wrote:
# Claws
* Check that the profile works and is torified (specifically the
EHLO/HELO SMTP messages it sends). Send an email using Claws and a
non-anonymizing SMTP relay. Then check that email's headers once
received, especially the `Received:` and `Message-ID:` ones.
* Also check that the EHLO/HELO SMTP message is not leaking anything
with a packet sniffer: start Claws using the panel icon (which runs
`torify claws-mail`) to
avoid using the transparent proxy (which will confuse tcpdump).
Disable SSL/TLS for SMTP in Claws (so take precautions for not
leaking your password in plaintext by either changing it temporarily
or using a disposable account). Then run `sudo tcpdump -i lo -w
dump` to capture the packets before Tor encrypts it, and check the
dump for the HELO/EHLO message and verify that it only contains
`localhost`.
We have a regression here. EHLO/HELO messages leaks the hostname
('amnesia'), resulting in '*@amnesia' Message IDs, and 'amnesia' in
the last Received field. I managed to track down the culprit: torsocks.
We start claws-mail with torify, which uses torsocks over tsocks.
Switching back to tsocks, like in 0.11 and previous releases, fixes the
leak.
If tsocks really is good enough, here is a quick and dirty hack, hastly
tested in the wild, no time for a proper patch:
1. Create `/usr/bin/torified-claws-mail` (perm 755) with:
#!/bin/sh
TSOCKS_CONF_FILE=/etc/tor/tor-tsocks.conf tsocks.distrib claws-mail
2. Update .desktop (applications and shortcut icon) to use
`torified-claws-mail`.
I have only gone so far to look upon /proc/$PID/maps to see that
libtsocks was indeed loaded. I don't know if that fixes the regression
or introduce others.
This is not the nicest, but we have in mind to ditch Claws soon enough.
--
Ague
pgpyYoxynyjiI.pgp
Description: PGP signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] [RC] writable system disk
On Sun, Jun 10, 2012 at 12:15:11PM +0200, anonym wrote: 06/09/2012 05:33 PM, intrigeri: anonym wrote (09 Jun 2012 13:32:55 GMT) : re-posting here in the hope it can be fixed in time for 0.12: https://tails.boum.org/bugs/writable_system_disk:_belongs_to_floppy_group/ Fixed in branch bugfix/writable_boot_media. Any comments before I merge it? Does it break tails-persistence-setup? Not according to my testing. Good job, then! :) Let's merge this in the next release and see if we get any complains. Users can always setup an administration password and get root access. It does not look like the bug is going to be fixed in udev itself. Should we push that fix upstream to live-boot? -- Ague pgpiVJqruVMUp.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Improvement of the shutdown sequence
On Sun, Jun 03, 2012 at 02:17:53PM +0200, intrigeri wrote: Great work. Comments follow. We now use this mechanism instead of having to call update-rc.d manually, something quite error prone. Best example is that 'ttdnsd' is actually requiring to be started after 'tor', but that fact was previously overlooked. I obviously agree with the general idea, but FTR I think this example is plain wrong: this was not overlooked (see the 60-ttdnsd.sh NM dispatcher hook). I have noticed the dispatcher hook, and I have indeed verified that the 'restart' call to the initscript would start the daemon if it was not already done. But still, ttdnsd is currently started at boot time, and at this point, it is not in working conditions, as Tor is not started. This is the kind of situation that insserv detects nicely. +++ b/config/chroot_local-includes/etc/insserv/overrides/gdomap @@ -0,0 +1,11 @@ +### BEGIN INIT INFO +# Provides: gdomap +# Required-Start:$remote_fs $syslog +# Required-Stop: $remote_fs $syslog +# Default-Start: +# Default-Stop: 0 1 6 2 3 4 5 +# Short-Description: Start the GNUstep distributed object mapper +### END INIT INFO Do we really need to duplicate that much of the header, instead of just overriding the field we want to change? Unfortunately, yes. If insserv forces us to do so: I agree such overrides are better than manually patching initscripts or using update-rc.d when we previously did so, but for other cases (I mean, initscripts we did not hack in any way previously), I seriously doubt the added maintenance cost is worth a quicker non-emergency shutdown. Tails shutdown sequence should be as fast as possible. This is probably nitpicking, but such an unbacked assertion means little to me, especially since we already have a totally separate emergency shutdown procedure. It finally hit me and I finally found that emergency procedure in `/usr/local/sbin/udev-watchdog-wrapper`. It was not that obvious to me before that. With persistence, I feel less inclined to just pull an USB stick to shut down Tails; loosing data is not something I like on a daily basis. But after pressing the top right red button, I don't like to wait before pulling it out either. In my eyes this is enough to try to reduce time spent in the shutdown sequence. I don't feel those headers are that much work. It looks to me as a work that has to be done once for each Debian release. But I understand your concerns. In the current incarnation of `feature/shutdown_cleanup`, there also is a significant pause in the 'live' script. Some of it because it reads files it will need after ejecting the system medium. Something we already do with `memlockd`… This is worth some more investigation as well. -- Ague pgplz3jtl3jMB.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] [PATCH tails-greeter] Enable users to select layout variants
On Mon, Jun 04, 2012 at 04:57:00PM +0200, a...@boum.org wrote: The 'Other…' entry for layouts now also list all variants for a given country layout. This should help Bépo and Dvorak users to enter their passphrase. Nice, thanks! --- GdmGreeter/language.py | 26 -- 1 files changed, 20 insertions(+), 6 deletions(-) Doesn't this patch miss changes in GdmGreeter/langpanel.py and glade/langpanel.glade ? I don't understand. What would you like to change there? This patch just adds more choices to the very same list that was displayed before using the very same presentation. -- Ague pgpbqjzbGh5R1.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
