Re: [Tails-dev] Please merge feature/Tor_0.2.3
Ague Mill wrote (25 Sep 2012 22:21:28 GMT) : Reviewed, merged in devel. Thanks! (I added the pending tag that was forgotten.) ___ 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
Hi, 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 :) 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. But this is only a remark in passing, and clearly no blocker for merging IMHO. 47629ce Update bug status and known issues Candidate for next release (point or major). Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review bugfix/default_search_engines
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] Documentation : proposed improvements
On 02/05/12 11:57, sam_tn...@hushmail.com wrote: Hello, When installing tails for the first time yesterday, i was a bit lost in the documentation. Here's the path I followed : Documentation Get Tails. Here I get and verified the Tails image, it was OK. But then : First steps with Tails. It's never said in the page Installing onto USB stick or Manually install Tails onto another USB stinck that it's now OK, that I can start Tails by rebooting on the USB stick. In the page manually..., the last thing I read before troubleshooting is The whole process might take some time, generally a few minutes. Be patient…. I see 2 ways of fixing that : 1. Only to these pages, adding Now, you can [[start]] Tails (redirecting to the page https://tails.boum.org/doc/first_steps/start_tails/index.en.html ) and, if needed and [[install Tails]] to another USB stick from your fresh new Tails to activate persistence support. 2. More generally, automatically add a link below every page towards the next page in the documentation (following the order given in the index page). 'hope this helps, Thanks for the suggestion. I tried to fix this, see the bottom of: - https://tails.boum.org/doc/first_steps/usb_installation - https://tails.boum.org/doc/first_steps/manual_usb_installation/linux - https://tails.boum.org/doc/first_steps/manual_usb_installation/windows signature.asc Description: OpenPGP digital 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
Hi, Ague Mill wrote (26 Sep 2012 08:48:21 GMT) : Great work! I am happy to see how the implementation turns out. :) Thanks for the review. +++ 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. Fixed (64ad230e). +++ 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. Fixed (4863fe7). +++ 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 :) +++ 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. Fixed (62a1e61). BTW, contribute/design/Tor_enforcement/DNS has another outdated instance of firewall.conf. +++ 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 Sure (f30c4f9). +Applications are configured to use the right SOCKS port: 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. No tests done so far. This one deserve to be looked at closely. Sure. Let's keep in mind it has been in experimental for a few weeks. I think we should go through the list of networking applications again (from the good old move to torsocks days), and make sure they all work as intended. I did it once already when developing this branch, but an additional pass before merging would be enough. Volunteers? (If there are any, I've just pushed my latest fixes, and merged into experimental again, but I think the tests should be conducted, if possible, on devel + feature/separate_Tor_streams rather than experimental. Just to be on the safe side. BTW, once this branch is merged, I think I'll reset --hard experimental to a saner state.) 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. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review 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
24/09/12 23:11, intrigeri wrote: Hi, whoever is the Release Manager for the current release cycle: please announce the freeze / RC / etc. dates ASAP. If I'm not mistaken, and if we don't change the release schedule this time, we're supposed to freeze in *one* week. But well, this is subject to change. Indeed. Looking at my own schedule I saw that this is the case, which I must say took me a bit my surprise given how recently we released 0.13... I think we're supposed to release on week 43, but... how do we deal, next time, with an unpredictable iceweasel backports schedule? I'm happy to focus on our APT repository for the next cycle, and it looks like bertagaz is making great progress on the build our own iceweasel front, but still, I'd rather not see us assume we'll be autonomous in this area in time for the current release cycle. So, for the current cycle, I suggest we patch our draft release schedule from the theoretical: / 3w\/ 2w /2|5d\ major freeze firefox release RC1 ESR | | | | | | RC2 release | | | | | ↓ ↓ ↓ ↓ ↓ ._._._._._._. 0 1 2 3 4 5 6 To the more realistic: / 3w\/ 2w /2|5d\ major freeze ESR release RC1 backport is available | | | | firefox | | ESR is out | | | | | | | RC2 release | | | | | ↓ ↓ ↓ ↓ ↓ ._._._._._._. 0 1 2 3 4 5 6 ?? (This implies releasing two weeks later than planned, that is week 45. Also, this assumes the backport is available two weeks after ESR is released. Yeah, that's way too late, but we'll soon be able to do better.) Unless we can get some sort of promise from Mike Hommey that the next Iceweasel ESR will be backported earlier than previously, your proposal indeed seems unavoidable. 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. The release cycle/schedule we decided on was a failure, so I see no reason to stick with it. Well, failure is a bit hard, but let's say premature; once we have our infrastructure ready so we don't have to depend on external parties' timely packaging I think it'll be great to return back to. *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. Cheers! signature.asc Description: OpenPGP digital 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] [patch, please review] generate Iceweasel profile at build time
25/09/12 10:31, Ague Mill wrote: 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... Note that there are other aspects of Iceweasel that we may want to make persistent, like the changes made by the certificate manager. With a pre-generated Iceweasel profile, that could be solved in the same way as with bookmarks. Without it, there would be need for another dedicated extension. However, todo/persistence_preset_-_bookmarks has been updated and it seems that making the bookmarks persistent using this approach may be trickier than I initially thought. Cheers! signature.asc Description: OpenPGP digital signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review bugfix/hide_TailsData_volume
Hi, 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. I can't find a ticket for this issue. Please file one or point me to the ticket I have missed. Cheers -- pgpGzBNo8t0lF.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
Hi, So, I'm proposing the following plan to release this feature: I think we agreed on this proposal. 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 This is done. 2. When 0.13.x point-releases are out, write developers documentation and tools, prepare IUK, update update-description files, ask beta testers to try the incremental upgrade process. Catch and fix most remaining bugs. What is the state of this phase? Will we do that for the next release? If it's not a point release, then when will we do that? Write user documentation [4] and hand it to translators. sajolida, do you want/plan to write the user documentation? Yes! I would be happy to work on that. I haven't done much work on the documentation since the persistence volume but that's sound like the perfect opportunity to catch up. What's the progress of the documentation? 3. Once we're happy with the whole thing, ship it, enabled by default, in the next Tails major release (that is, presumably 0.14, unless 1.0 is due already -- who knows :) Cheers -- pgpdoabLsVUEl.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
Hi, From: berta...@ptitcanardnoir.org Date: Mon, 24 Sep 2012 11:28:28 +0200 Tested, works, merged into devel. Well done! I can't find it on devel. Did I miss something ou did you forget to push? -- pgpbOPbBgnVZq.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Download manager
Hi, There are 20 ticket currently tagged discuss. I'm choosing 3 of them to launch discussions. 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]] Cheers -- pgpBcK6O4bYsB.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.
Hi, We didn't reach a conclusion on this topic. The page on pcmcia is still tagged discuss. 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.? * 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. This is related to [[https://tails.boum.org/todo/disable_expresscard__36__]] Please give your thoughts. Cheers -- pgpsLd1OZy4tU.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] WhisperBack issue
Hi, I think that we have to add a whisperback release fixing this bug for 0.13.1/0.14. I volonteer for doing it. Cheers From: a...@boum.org Date: Mon, 17 Sep 2012 13:33:05 +0200 Hi, Summary: I have been reported an usability issue in whisperback 1.6, which is solved in git. Bug description: if an error happens while sending a bug reoport, the user is asked to try again. But even if this second attempt is successful, the same error was reported. The user is asked to save the bug report and try to send it another way, even through the bug report was actually sent. Solution: this was due to a variable missing reinitialisation before a new send attempt. This issue is solved in git (commit 1ec71b0). Cheers -- ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev -- pgpaKYKncvR4y.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 Wed, Sep 26, 2012 at 07:43:22PM +0200, a...@boum.org wrote: Hi, From: berta...@ptitcanardnoir.org Date: Mon, 24 Sep 2012 11:28:28 +0200 Tested, works, merged into devel. Well done! I can't find it on devel. Did I miss something ou did you forget to push? Damn you nitpicker! :) My fault, I did a simple merge and forgot the --no-ff option :/ How can I solve this? bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] please look at Comparison of Whonix, Tails and TBB
Hello, I created a Comparison of Whonix, Tails and TBB [1] [2] for the upcoming Whonix release 0.4.4 which will soon be released. At that point probable some users have a look on that page. If there is anything wrong, I'll correct it right away. Cheers, adrelanos [1] https://sourceforge.net/p/whonix/wiki/Security/#comparison-of-whonix-tails-and-tbb [2] https://sourceforge.net/p/whonix/wiki/Security/#attacks ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
