Re: [Tails-dev] Round of translation uploads

[Ague Mill]

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] Please review and merge feature/sinhala-font

[Ague Mill]

intrigeri:
> please review and merge feature/sinhala-font.
> 
> Quickly tested (build devel + feature/sinhala-font ISO, booted,
> checked that the si.wikipedia.org website looks much better than in
> 0.14; same for some random text pasted into OO.o and selecting the
> LKLUG font). Not merged into experimental due to the currently broken
> state of that branch that I'm not in the mood to fix right now.

I've took care of the later.

Works in my tests.

-- 
Ague


pgpIugvbjLcKp.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/gpgApplet_menu_in_bottom_panel

[Ague Mill]

anonym:
> Here's a small post-freeze bugfix for Tails 0.15 which fixes the
> gpgApplet menu issue reported when using the Windows XP camouflage.
> 
> Branch: bugfix/gpgApplet_menu_in_bottom_panel
> Ticket: https://tails.boum.org/todo/fix_gpgApplet_with_Windows_camouflage/

> diff --git a/config/chroot_local-includes/usr/local/bin/gpgApplet 
> b/config/chroo
> index 71932ec..f5d1568 100755
> --- a/config/chroot_local-includes/usr/local/bin/gpgApplet
> +++ b/config/chroot_local-includes/usr/local/bin/gpgApplet
> @@ -161,7 +161,7 @@ b) the "Artistic License" which comes with Perl.
>  my $time = shift;
>  my ($x, $y, $push) = Gtk2::StatusIcon::position_menu($menu, $ticon);

The change that follows makes this line useless, or did I miss anything?

>  $menu->show_all;
> -$menu->popup(undef, undef, sub {($x, $y,$push)}, undef, $event, 
> $time);
> +$menu->popup(undef, undef, undef, undef, $event, $time);
>  });
>  
>  $icon->signal_connect('button-press-event' => sub {

-- 
Ague


pgphsdfa3Lauo.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/bridge_mode_vs_tor_restarts

[Ague Mill]

Ague Mill:
> anonym:
> > anonym:
> > > Here's a small post-freeze bugfix for Tails 0.15 which fixes the issue
> > > with bridge mode + tordate discovered by ague. It's merged into
> > > experimental.
> > > 
> > > Branch: bugfix/bridge_mode_vs_tor_restarts
> > > Ticket: https://tails.boum.org/todo/bridge_mode_vs_tor_restarts/
> [...] 
> This part makes me nervous.

Other than that, my tests have shown that it fixes the original issue.

-- 
Ague


pgpih20YJ9MH5.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/bridge_mode_vs_tor_restarts

[Ague Mill]

anonym:
> anonym:
> > Here's a small post-freeze bugfix for Tails 0.15 which fixes the issue
> > with bridge mode + tordate discovered by ague. It's merged into
> > experimental.
> > 
> > Branch: bugfix/bridge_mode_vs_tor_restarts
> > Ticket: https://tails.boum.org/todo/bridge_mode_vs_tor_restarts/
> > 
> > commit 3f876314055b83f1aacd5ed790d03bad411a8aae
> > Author: Tails developers 
> > Date:   Thu Nov 15 16:56:26 2012 +0100
> > 
> > Create wrappers for (re)starting Tor and Vidalia.
> > 
> > If Vidalia is running, and Tor is restarted, then we also want to
> > restart Vidalia. This is because Vidalia doesn't re-connect to Tor
> > automatically, so the user has to restart it to be able to control Tor
> > again. Also, any options set by Vidalia will be lost since they
> > weren't written to torrc, which causes Tor to reach an inactive state
> > if it's restarted in "bridge mode".

Quoting the diff:

> --- a/config/chroot_local-includes/usr/local/sbin/unsafe-browser
> +++ b/config/chroot_local-includes/usr/local/sbin/unsafe-browser
> @@ -203,15 +203,10 @@ maybe_restart_tor () {
>  # wheels turning)
>  if ! tor_is_working; then
>  echo "* Restarting Tor"
> -if ! service tor restart; then
> +restart-tor
> +if ! service tor status >/dev/null; then
>  error "`gettext \"Failed to restart Tor.\"`"
>  fi
> -local counter=0
> -until [ "${counter}" -ge 10 ] || nc -z localhost 9051
>  2>/dev/null; do
> -sleep 1
> -counter=$((${counter}+1))
> -done
> -/etc/NetworkManager/dispatcher.d/60-vidalia.sh clearnet up
>  2>/dev/null
>  fi
>  }

This part makes me nervous. Previously there was a timer that would try
several time before displaying an error message. This change would mean
that tor needs to have its pid file ready really fast to prevent the
error message from being displayed…

I think keeping a small loop, or at least sleeping for a few seconds
would be better.

-- 
Ague


pgpoUrnv6DVns.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]

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 test Tails 0.15~rc1!

[Ague Mill]

Hi!

The first release candidate for Tails 0.15 is out:


Happy testing!

-- 
Ague


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

[Ague Mill]

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

Re: [Tails-dev] Trying tails-create-iuk

[Ague Mill]

intrigeri:
> > Using `sudo`,
> 
> Thanks.
> 
> > as the suggested in the documentation.
> 
> May I ask which part of it? I did not find this easily.
> (I'd like to improve this after gathering my thoughts, tests, time and
> everything else needed.)

The release process contains the following command line:

  Build the Incremental Update Kit

  Example:

  $ sudo tails-create-iuk --squashfs-diff-name 0.14.squashfs \
--old-iso tails-i386-0.14\~rc2.iso \
--new-iso tails-i386-0.14.iso  \
--outfile Tails_i386_0.14-rc2_to_0.14.iuk



That's more or less what I have tried to run (except for absolute paths
and version numbers).

-- 
Ague


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

[Ague Mill]

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] Trying tails-create-iuk

[Ague Mill]

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

[Tails-dev] Please review bugfix/handle_apt_sources_for_rc

[Ague Mill]

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

Re: [Tails-dev] Bookmarks persistence - help needed

[Ague Mill]

intrigeri:
> Please do consider that it might be remotely possible that one did not
> understand your actions and emails the way you think they should have.

This shows that this is, indeed, a misunderstanding.

If it could have been possible (tails-persistence-setup would not have
been a blocker), I would have merged the branch directly to devel,
because I felt the patches written by Alessandro were good enough to be
included. They had been discussed on the mailing-list between Sep 22th
and Oct 15th and also with anonym over IRC. So yes, I assumed other
Tails developers had enough opportunity to look it up if they had time
and energy.

I have to acknowledge that you do not trust my judgement for such
matters.

> ["think positive" conclusion: "please review" in email subject helps.]

I will limit myself to such requests for the time being.

-- 
Ague


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

[Ague Mill]

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] Bookmarks persistence - help needed

[Ague Mill]

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:


The documentation was subsequently edited by sajolida two days later:


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] network.proxy.socks_remote_dns and localhost

[Ague Mill]

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

[Tails-dev] Round of translation uploads

[Ague Mill]

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] config/chroot_local-packages is now deprecated

[Ague Mill]

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

Re: [Tails-dev] config/chroot_local-packages is now deprecated

[Ague Mill]

intrigeri:
> I've just reviewed the already merged move-to-APT-repo work,
> and pushed what I believe is a needed bugfix commit on top of it.
> 
> I must say that in general, I'm no great fan of last minute big
> changes, the day before the freeze, without any proper review and
> merge request process.

Well, I have done a careful review of the resulting package set and it
was identical before and after the switch. So this change was not
affecting our final product.

Your last commit (ba704e641ca) means that currently, we will build with
live-config/3.0.12-1 and live-boot/3.0~b7-1. I have neither done any
tests with these versions nor look at their changelogs. Did you? Do you
think it is a safe move?

-- 
Ague


pgp022Np3Y30l.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]

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

[Tails-dev] network.proxy.socks_remote_dns and localhost

[Ague Mill]

Hi!

Since we now include Torbrowser patches, we gained the
`network.proxy.socks_remote_dns` preference.

Its implemented in:


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

[Tails-dev] config/chroot_local-packages is now deprecated

[Ague Mill]

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:


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] Bookmarks persistence - help needed

[Ague Mill]

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

Re: [Tails-dev] Please review and merge feature/obfsproxy

[Ague Mill]

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] Tails 0.15 release schedule

[Ague Mill]

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

[Ague Mill]

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] Please review and merge feature/korean_input

[Ague Mill]

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 bugfix/no-console-setup-on-X

[Ague Mill]

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] Idea or something

[Ague Mill]

(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 . 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
 and contribute section
.

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

[Ague Mill]

anonym:
> What procedure do you suggest for packages that we don't build
> ourselves, like live-config{-sysvinit}? The APT documentation [1] only
> covers the case where packages are built and an appropriate .changes
> file is generated.
> 
> Should I try to manually write a .changes file, e.g. by adapting the
> upstream one, removing references to other packages like live-config-doc
> etc.?
> 
> Or should I build the packages? What about all these irrelevant packages
> (like live-config-doc) then? Upload them too?

The main difference of using our APT repository versus
`chroot_local-packages` is that packages in the former won't
automatically be installed. So there is no reason to exclude binary
packages. They might come in handy later (binary packages containing
debug symbols, for example).

You can write a .changes manually, but it might be easier to use the
changestool(1) command that is shipped in the reprepro package.
Rebuilding the package is another fine option unless the build
ecosystem has changed too much in the meantime.

If the whole thing feels complicated, just put it in
`chroot_local-packages` and we'll deal with the rest with 0.15.

-- 
Ague


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

[Ague Mill]

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] Progress report on the automated test suite

[Ague Mill]

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


> 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
,
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] Tails 0.15 release schedule

[Ague Mill]

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] Switch to Privoxy?

[Ague Mill]

adrelanos:
> > APT: a rough initial test was done, that added a tor+http shim in
> /usr/lib/apt/methods IIRC, to add torsocks in the loop. It worked fairly
> well, but one of the late live-build scripts insists on running APT,
> which fails in this configuration.
> 
> Now that torsocks is unmaintained (see extra thread), I am not sure it
> is a good idea to rely on torsocks to torify apt.

torsocks is free software. If it is unmaintained but the software is
still relevant, then it'll find new maintainers. If we really need it in
Tails, maybe it will fall on our plate.

And even we could still replace it with tsocks or proxychains or some
other LD_PRELOAD based solution.

> Afaik torsocks has no IPv6 support, only an IPv6 leak bug.

I am pretty sure both could be addressed.

-- 
Ague


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

Re: [Tails-dev] wpolipo - polipo manger init script to improve Tor stream isolation

[Ague Mill]

adrelanos:
> I am writing an init script for polipo, which makes it easier to open
> multiple http proxy listen ports and to forward them to different Tor
> parent socks ports for easier Tor stream isolation:
> https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/Polipo
> 
> Anyone interested?

Our last discusions for Tails about polipo were in the lines of "let'se
just remove polipo from the system".

We are currently done to only two major users of an HTTP proxy: APT and
wget.  For the first we have successfully pulled an interesting trick
that needs a little bit more research. The later might be just be
removed and users taught to use curl instead...

See: 

-- 
Ague


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

[Ague Mill]

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] Debian popularity contest

[Ague Mill]

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] [PATCH] Remove the last absolute path in our SYSLINUX config

[Ague Mill]

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] Tails 0.14 vs. iceweasel 10.0.9esr-1

[Ague Mill]

intrigeri:
> a quickly tested ISO image, based on Tails 0.14~rc1, built from our
> feature/torbrowser Git branch, should be available there in a hour or
> so:
> 
>   
> http://dl.amnesia.boum.org/tails/testing/tails-i386-feature_torbrowser-0.14~rc1-20121024/
> 
> It ships with iceweasel 10.0.9esr-1+tails1, that is iceweasel
> 10.0.9esr-1 patched with (almost all) the torbrowser patches.

I have done some tests and reviews.

It lead me to discover a fingerprint issue related to window sizes. It
also affects the TorBrowserBundle and has been reported here:
https://trac.torproject.org/projects/tor/ticket/7222

No comments on the implementation, except maybe that
0019-Adapt-Steven-Michaud-s-Mac-crashfix-patch.patch looks Mac only. But
then, no harm done in applying it to our custom Iceweasel sources.

So far, so good. My opinion is to push that to rc2. :)

-- 
Ague


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

[Ague Mill]

intrigeri:
> a quickly tested ISO image, based on Tails 0.14~rc1, built from our
> feature/torbrowser Git branch, should be available there in a hour or
> so:
> 
>   
> http://dl.amnesia.boum.org/tails/testing/tails-i386-feature_torbrowser-0.14~rc1-20121024/
> 
> It ships with iceweasel 10.0.9esr-1+tails1, that is iceweasel
> 10.0.9esr-1 patched with (almost all) the torbrowser patches.

Amazing. :)
 
> Please test and report back. To get more testers on it, I'll announce
> it in news/ and on IRC tomorrow unless someone beats me to it.

I would rather postpone the larger call to 0.14~rc2. Unless something is
very wrong with your solution, we scheduled 0.14~rc2 for just next week,
and calling for tests twice in such short timeframe is more likely to
wear testers out, IMHO.

-- 
Ague


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

[Ague Mill]

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  
> >> 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] torbrowser.version vs. torbutton [Was: Tails 0.14 vs. iceweasel 10.0.9esr-1]

[Ague Mill]

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] Fwd: [tor-reports] Trip Report: GSoC Mentor Summit

[Ague Mill]

On Mon, Oct 22, 2012 at 07:37:50AM +0200, intrigeri wrote:
> might Mailman 3 be yet another candidate for our forum?

Our current experience (and previous analysis) lead us to agree that
what we needed was a community centered self-support system, not a
free-for-all forum. Web applications built around questions, answers and
user's reputation should lead to way better knowledge building.

(Also, it's been years that I hear that Mailman 3 is going out "in
around 6 months".)

-- 
Ague


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

[Ague Mill]

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

[Ague Mill]

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] Tails 0.14 vs. iceweasel 10.0.9esr-1

[Ague Mill]

On Sat, Oct 20, 2012 at 10:01:24AM +0200, intrigeri wrote:
> Ague Mill wrote (18 Oct 2012 19:36:53 GMT) :
> > 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.
> 
> Wow. I've had a look.
> Yes, I feel it's too much of a hack, but that's a mere feeling.
> 
> E.g. I don't like the fact this couples components shipped by Debian's
> iceweasel (such as language packs) with components shipped by TBB
> (such as the torbrowser binary). I'm not comfortable with adding (at
> the binary level) to the inter-dependency mix we're in, and that is
> hitting us right now.

Just to make it clear: this was proposed as a very temporary solution so
we can actually release 0.14 without compromising users anonymity too
much. This hack is hideous enough that it really can't stay there.

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.

> Also, I guess this hack would require at least some more hours of work
> to be in a releasable state.

Given that the resulting browser works fine, I don't think it would
require more time than building a custom Iceweasel and setting up a
temporary repository. Sure, this is a waste of work for even mid-term,
but that's a tunnel with an end already in view.


This Firefox "point-release" is putting us in a really bad situation.
Between two release candidates is not the ideal time to find the best
solution for our browser issues.

Anyway, given we are not able to release a working Tails 0.14 with
security fixes right now, we could also simply forget the schedule and
instead of rushing dirty solutions, delay 0.14 until we have both neat
Iceweasel packages and definitive APT repositories.

-- 
Ague


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

[Ague Mill]

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

[Ague Mill]

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

Re: [Tails-dev] Tails 0.14 vs. iceweasel 10.0.9esr-1

[Ague Mill]

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

[Ague Mill]

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

[Ague Mill]

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

[Tails-dev] tails-persistence-setup and feature coupling

[Ague Mill]

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

-- 
Ague


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

[Tails-dev] Images on doc/first_steps/persistence/configure broken in offline documentation

[Ague Mill]

Hi!

The source for the `doc/first_steps/persistence/configure` pages
contains:



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.

-- 
Ague


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

[Ague Mill]

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

Re: [Tails-dev] Upstreaming yelp patch

[Ague Mill]

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] Tails: pcmcia / firewire / etc.

[Ague Mill]

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] Design doc update

[Ague Mill]

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

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] Upstreaming yelp patch

[Ague Mill]

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] Bookmarks persistence - help needed

[Ague Mill]

On Wed, Oct 10, 2012 at 07:03:20PM +0100, Alessandro Grassi wrote:
> > What is also needed before we can merge this work is an update to the
> > design documents and the end-user documentation, see
> >  for details.
> > Do you want to carry on your work on this front as well?
> 
> I'll do it ASAP, possibly 1 or 2 days. Is it too late to have this
> feature in 0.14?

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.

-- 
Ague


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

[Ague Mill]

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

[Ague Mill]

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] Bookmarks persistence - help needed

[Ague Mill]

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

[Tails-dev] Please review feature/hugetlb_mem_wipe

[Ague Mill]

Hi!

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

So, here it is, in the `feature/hugetlb_mem_wipe` branch. It keeps a
Linux+initramfs+userland program approach, but it does so with a little
hand-crafted C program.

That piece of software uses mmap and hugetlb and some Linux vm tricks to
wipe as much as possible. And for an added bonus, with a progress bar.

See the commit message for more details.

If have successfully tested that code in a VM with more than 4 GB memory
and it looks like it works. I was not able to properly analyze the
memory with that much bytes, though.

I'll be happy if someone could do so more testing in >= 4 GB conditions
as I am lacking the necessary hardware at the moment. I'd be interested
in knowing how this branch compares with the current state of devel,
both in time and on how much memory is actually overwritten.

Provided a little more feedback, this could go in 0.14. We can always
revert if rc1 proves it deficient.

-- 
Ague


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

[Tails-dev] [PATCH] sdmem is only called once in initramfs script

[Ague Mill]

Hi!

While working some more on memory wipe issues, I noticed that the
current `sdmem` initramfs script calls `seq` to start multiple `sdmem`
process. Unfortunately, `seq` is unavailable in the ramdisk environment.

This trivial patch should make the script start more than one sdmem
process again:

diff --git a/config/chroot_local-includes/usr/share/initramfs-tools/hooks/sdmem 
b/config/chroot_local-includes/usr/share/initramfs-tools/hooks/sdmem
index dc34f86..cd20e71 100755
--- a/config/chroot_local-includes/usr/share/initramfs-tools/hooks/sdmem
+++ b/config/chroot_local-includes/usr/share/initramfs-tools/hooks/sdmem
@@ -21,3 +21,4 @@ esac
 copy_exec /sbin/halt
 copy_exec /sbin/reboot
 copy_exec /usr/bin/sdmem
+copy_exec /usr/bin/seq

No tests done yet, but I can't see how it could make the situation
worse.

-- 
Ague


pgpsGnNRGzYxo.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]

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 and merge feature/persistent_NM_connections [was: tails-persistence-setup releases vs. Tails 0.14]

[Ague Mill]

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

[Ague Mill]

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] Shipping a 686-pae kernel

[Ague Mill]

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] Shipping a 686-pae kernel

[Ague Mill]

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] Please review and merge feature/persistent_NM_connections [was: tails-persistence-setup releases vs. Tails 0.14]

[Ague Mill]

>   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] Faking htpdate user agent worth it?

[Ague Mill]

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

[Ague Mill]

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] Please review and merge bugfix/iceweasel_file_associations

[Ague Mill]

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

[Ague Mill]

On Sun, Sep 30, 2012 at 07:28:04PM +0100, Alessandro Grassi wrote:
> > [...] If the symlink points to a non-existent file, then Firefox will
> > happily create it [...]
> Correct, I tried it too. This is ok for when no places.sqlite exists.
> If it exists, user may have some saved bookmarks already, and we should
> preserve them.

Other bits of configuration are not saved until a new session is started
in which the persistence volume is activated. So there is no need to worry
about this: the first time a newly created persistence volume is
activated, it will get the default set of bookmarks. Changes will be
kept from then on.

-- 
Ague


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

[Ague Mill]

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

[Ague Mill]

On Sat, Sep 29, 2012 at 08:54:22PM +0200, intrigeri wrote:
> this branch adds a Japanese input system (scim-anthy) that was asked
> on the forum. I've asked for tests, and was asked for an ISO.
> So I suppose we should add this package, and call for
> Japanese -speaking testers at RC1 or RC2 time.
> 
> Candidate for 0.14, has been living in experimental for ~2 weeks.

Merged in devel.

-- 
Ague


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

[Ague Mill]

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
 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()`


Unfortunately, while it looks fairly easy to do from Python when using
GLib, according to the answers on this page
,
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] Tails: pcmcia / firewire / etc.

[Ague Mill]

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] Download manager

[Ague Mill]

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 webbrowser homepage

[Ague Mill]

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  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  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] Improvement of the shutdown sequence

[Ague Mill]

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

[Ague Mill]

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

[Ague Mill]

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

[Tails-dev] Please review bugfix/default_search_engines

[Ague Mill]

Hi!

The branch bugfix/default_search_engines fixes the default search
engine selected for Portugese and Spanish.

Short log:

  46a7885 Fix localized search plugins for 'es' and 'pt'
  f9d73a5 Be consistent when giving a locale to check.torproject.org
  47629ce Update bug status and known issues

(Yes, the second is not strictly related.)

Candidate for next release (point or major).

-- 
Ague


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

[Ague Mill]

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] Block/unblock wireless devices?

[Ague Mill]

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] Improvement of the shutdown sequence

[Ague Mill]

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

[Ague Mill]

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

[Tails-dev] Please review feature/use_ferm

[Ague Mill]

Hi!

The branch feature/use_ferm turns our DIY iptables-restore script into a
ferm configuration file. See  for
details.

Comparing the output of `iptables-save` with the one of 0.13, I have
only this minor difference:

--A OUTPUT -d 127.0.0.1/32 -o lo -p tcp -m owner --uid-owner amnesia -m tcp 
--dport 9051 --tcp-flags FIN,SYN,RST,ACK SYN -j ACCEPT 
+-A OUTPUT -d 127.0.0.1/32 -o lo -p tcp -m owner --uid-owner amnesia -m tcp 
--dport 9051 -j ACCEPT 

Which, as a matter of consistency, is probably better.

Reviews welcome, candidate for the next major release.

-- 
Ague


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

[Tails-dev] Please review feature/catch_errors_in_hooks

[Ague Mill]

Hi!

Alessandro's email earlier on reminded me that most of our hooks were
actually not using `set -e` and had the habit of going past errors.

So, I am asking reviews of the feature/catch_errors_in_hooks branch.
Short log:

4642a61 Catch more errors in local hooks
5653409 Fail hard if adduser fails in local hooks
dd2a001 Fail hard if 'rm' fails in local hooks
bb45a71 Remove uneeded chroot_local-hooks/15-fix_X11
610428b Remove chroot_local-hooks/11-clean_live-initramfs_scripts
ed512d0 Do not try to remove non-existing /var/lib/dkms/virtualbox-guest
d3e3b76 Remove the correct gcc symlink in virtualbox hook

The first three commits tighten error processing. The others are fixes
for the newly detected errors.

Candidate for next major release.

-- 
Ague


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

[Ague Mill]

On Sat, Sep 22, 2012 at 07:04:25PM +0100, Alessandro Grassi wrote:
> attached patch should generate Iceweasel profile on build time, rather than
> run time. It is required for a "bookmarks" persistence preset (which I want
> to implement soon), as explained in the todo ticket:
> 
> https://tails.boum.org/todo/persistence_preset_-_bookmarks/
> 
> First time I send a patch, I hope it's ok :-)

Thank you for working on this! The patch in itself looks ok. :)

I know that you have future plans, but right now, what kind of benefits
would Tails get from generating an Iceweasel profile at build time?
Unless there is a clear answer to this question, I think it would be
better to wait until there is a complete patch set implementing
persistence for bookmarks.

How far have you tested this patch?

Does calling `iceweasel -CreateProfile` requires to have an X server
running?

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.

-- 
Ague


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

[Ague Mill]

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

[Ague Mill]

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 +0000, 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] Benchmarking Redmine

[Ague Mill]

> Ague, please add pointers, on our wiki page, to the "YAML export" and
> "email reminder for due dates" plugins you've discovered, so that
> anyone, possibly including me and Riseup and whoever wants, evaluates
> how they are hosting-friendly.

I don't remember about a YAML export. For the rest of what I had found I
pointers have been added to the wiki page.

-- 
Ague


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