[Tails-dev] please look at Comparison of Whonix, Tails and TBB

[adrelanos]

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

Re: [Tails-dev] Please review bugfix/fix_background_readahead

[bertagaz]

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

Re: [Tails-dev] Shipping a 686-pae kernel

[alan]

Hi,

> From: intrigeri 
> Date: Wed, 12 Sep 2012 11:05:56 +0200
> 
[...]
> 
> anonym wrote (06 Sep 2012 18:27:37 GMT) :
> > The crash occurs on my (64-bit) laptop. :/
> 
> Do you mean, on your own system (if so: both kernel / userspace
> 64-bits? Debian Wheezy?) or within Tails feature/multikernel with the
> 686-pae kernel?

I can't find an answer to this message. Was it answered somewhere else?

By the way, everybody please consider testing this feature on various
hardware, especially to see if "liveusb-creator crashes on amd64 kernel"
affects systems running the 686-pae kernel.

Cheers


-- 


pgpI8Tko5WcMG.pgp
Description: PGP signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] WhisperBack issue

[alan]

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

[Tails-dev] Tails webbrowser homepage

[alan]

Hi,

https://tails.boum.org/todo/decide_what_web_homepage_to_use reads:

iceweasel's homepage is currently set to
.

Our release process now includes quite thorough testing that makes us
confident enough in Tails configuration to instead use this very
website as the homepage.

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  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?

Cheers


-- 


pgpphnYdGROVB.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.

[alan]

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

[Tails-dev] Download manager

[alan]

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] Please review bugfix/fix_background_readahead

[alan]

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

Re: [Tails-dev] incremental upgrades: phase one almost done, release plan

[alan]

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/hide_TailsData_volume

[alan]

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] [patch, please review] generate Iceweasel profile at build time

[anonym]

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] Vagrant build problems

[Ague Mill]

On Tue, Sep 11, 2012 at 06:24:48PM +, Abel Luck wrote:
> I'm the Guardian Project developer working on the Clean Room idea for
> securely and easily managing PGP keys.
> 
> I'm trying to build tails using Vagrant and from the latest 'devel'
> branch but something seems to be dieing.
> 
> Here's the last 150 lines or so from 'rake build --trace'
> [...]

If I understood what was said on IRC, this was due to a mismatched
version between Virtualbox, and the Ruby gem of the same name. Right?
 
-- 
Ague


pgpSLFTVd91vS.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

[Ague Mill]

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] Next release: process, schedule and iceweasel backports

[anonym]

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] Please review feature/separate_Tor_streams

[Ague Mill]

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] Please review feature/separate_Tor_streams

[intrigeri]

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:
> 

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] Documentation : proposed improvements

[sajolida]

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 bugfix/default_search_engines

[Ague Mill]

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 bugfix/default_search_engines

[intrigeri]

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 feature/separate_Tor_streams

[Ague Mill]

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:


> +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 merge feature/Tor_0.2.3

[intrigeri]

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