[Tails-dev] Call for testing 0.14~rc2

[anonym]

Hi!

This is the 'official' call for testing the second release candidate of
the upcoming version 0.14 of Tails. Please test it and see if all works
for you. All information you need for this can be found here:



Happy testing!

___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Tails 0.14 rc1 virtualization testing & howto install virtualbox and vmplayer

[anonym]

29/10/12 19:54, a...@riseup.net wrote:

>>   IIRC, VirtualBox host software sets iptables/netfilter up in a way
>>   that makes the guest system bypass the existing firewall / or be
>>   blocked by it, so some care should be taken on this side.
> 
> One idea is to use host-only networking in the virtualbox guest, and the
> apps in the guest can connect to appropriate socks-port(s) on the hosts
> host-only adapter

Sure, a host-only adapter probably make this easier than the bridged
setup described in the link.

> Bridge mode is the problem, it would be worth checking if the amnesia user
> can leverage the virtualbox bridge kernel module/driver to bypass tor.
> This would violate tails design because currently the amnesia user is not
> allowed direct internet access.

This is interesting and certainly needs to be investigated further
(added to todo item). My initial testing shows that, indeed, bridged
adapters bypass the host's firewall.

> Bridge mode and NAT support could simply be left out alltogether from
> tails, any drivers deleted/not-installed

Allowing NAT is at least not a leaking-related problem since the NAT:ed
traffic appears "normally" in the host OS, so in Tails it will be caught
by the firewall.

> If the kernel modules for bridge and NAT adapters is left out of tails,
> that would leave only the host-only networking adapter.

vboxnetflt is used for bridged adapters, but host-only adapters requries
*both* vboxnetadp and vboxnetflt to be loaded.


___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Tails 0.14 rc1 virtualization testing & howto install virtualbox and vmplayer

[anonym]

29/10/12 21:38, anonym wrote:
> 29/10/12 19:41, a...@riseup.net wrote:
>> anonym wrote:
>>> Actually the Tails host I did this from was itself a VirtualBox guest,
>>> so it also shows that nested VMs work, but the nested-guest is slooow.
>>
>> How slow? Unusably slow? Would Tails need to do something different to
>> ship a virtualized tails solution?
> 
> Well, about as slow as running from DVD I'd say. It's mostly booting it
> up that takes time.

Apparently VirtualBox doesn't support hardware virtualization
(VT-x/AMD-V) if it's run inside a guest:

https://www.virtualbox.org/ticket/4032

Too bad, at least for people that don't run Tails directly on hardware,
but in a VM. That makes KVM look more attractive, although its GUIs are
less easy to use. Hmm.

Cheers!

___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Tails 0.14 rc1 virtualization testing & howto install virtualbox and vmplayer

[anonym]

29/10/12 19:41, a...@riseup.net wrote:
>> I did this from a fresh Tails session:
>>
>> sudo ln -s /usr/bin/gcc-4.4 /usr/bin/gcc-4.6
>> sudo apt-get update
>> sudo apt-get install --yes linux-headers-686-pae virtualbox-dkms \
>> virtualbox-qt
>> vboxmanage createvm --name Tails --ostype Debian --register
>> vboxmanage modifyvm Tails --memory 1024
>> vboxmanage storagectl Tails --name SATA0 --add sata \
>> --controller IntelAHCI
>> vboxmanage storageattach Tails --storagectl SATA0 --port 0 \
>> --device 0 --type dvddrive --medium host:/dev/cdrom
>> vboxmanage startvm Tails
>>
>> And then Tails starts as a guest within Tails, using the same boot
>> media (there's no need to copy in the image to ram like you did).
> 
> This would be great for Tails as we can use vboxmanage to modify the
> virtual tails as needed. I dont see Tails copying any ISO or filesystem
> into RAM anytime soon (and booting the VM from that), it does have high
> performance though compared to using the CD but really isnt necessary?

Sorry, but I don't understand what you mean here.

>> Actually the Tails host I did this from was itself a VirtualBox guest,
>> so it also shows that nested VMs work, but the nested-guest is slooow.
> 
> How slow? Unusably slow? Would Tails need to do something different to
> ship a virtualized tails solution?

Well, about as slow as running from DVD I'd say. It's mostly booting it
up that takes time.

> I havent tested using virtual tails from the same mechanical optical disk
> yet.

Me neither. But as long as the host has booted completely, there
shouldn't be much competition between the host and guest to read from
the media.


>>> * Allows stronger enforcement of tor-only connections, an attacker must
>>> break out of a virtual machine, in addition to previous steps taken. A
>>> VM
>>> can be configured to only be able to send traffic through the tor
>>> process
>>> running on the host machine.
>>
>> Sure, but to configure the applications in the guest to use the host's
>> Tor is non-trivial for most users (and would require us to make Tor's
>> ports listen on more than localhost). I'd like a way so a whole VM is
>> Torified without additional configuration inside the VM. Here's some an
>> article one can find inspiration from:
>>
>> 
> 
> I can see the low effort maintainability goal, and it could be quicker and
> easier to ship a virtualized tails that virtualises the entire VM, and
> maybe think about individual app & firewall configuration later
> 
> However I do note that currently the firewall has per application rules,
> and some apps have stream isolation, how much work would it be to have a
> slightly different firewall configuration, and tell the apps to use the
> same socks port, but vbox.guest.hostadapter.ip instead of localhost?
> 
> It would also need the bootmagic to be able to control which firewall
> script gets loaded

Exactly. We are talking about two different use cases, which are (1) and
(2) in what you outline below:

>>> * Enables the features described at
>>> https://tails.boum.org/todo/Two-layered_virtualized_system/
>>
>> Needless to say, including Virtualbox host software in Tails is only a
>> small step on the way to the above. There's still a lot of work left to
>> achieve it in a user-friendly way (i.e. zero user configuration).
> 
> Yes a small step along the way. A shipped virtualbox might get more people
> to start testing virtualization in tails.
> 
> 
> I see some use cases here:
> 
> (1) User wants an entire $any VM to be torified, this VM is not
> necessarily tails. They load they VM and the entire VM is torified through
> one socks port. Then they can run their $random windows app
> 
> 
> (2) Tails livecd IS the guest VM. Existing apps have exactly the same
> stream isolation because the tails guest apps are preconfigured to connect
> to vboxguest.hostadapter.ip:socksport
> 
> This does seem like alot of work, getting all the DNS reconfigured,
> virtual tails does look like it has alot of issues to be ironed out

I'm not sure it has to be so complicated. In the Tails guest
('app-guest' in my "design" below) we could use firewall rules to
redirect all traffic to the relevant local ports to the corresponding
ports on the Tails host (or 'tor-guest'). Or set up `socat` instances
that listens on e.g. port 9050 in the guest and forward them to port
9050 on the host (or 'tor-guest'). We could even write a short script
that runs in the Tails guest ('app-guest') and scans torrc for all
*Port:s and sets up the redirection accordingly.

Any sort of re-configuration is easy as long as it's Tails we're dealing
with. But for an arbitrary OS the best we can do is to Torify the whole
VM from the Tails host.

>> One interesting thing to note, though, is that the host can start
>> several guests using the same

Re: [Tails-dev] Tails 0.14 rc1 virtualization testing & howto install virtualbox and vmplayer

[adev]

> hi,
>
> a...@riseup.net wrote (26 Oct 2012 15:43:09 GMT) :
>> Tails 0.14 rc1 686-pae sees all my cpu cores and RAM
>
> Nice to hear.
>
>> Time to test virtualization.
>
> Ah. FYI this is tracked on
> https://tails.boum.org/todo/add_virtualbox_host_software/

Thanks, I'll see if I can add anything useful there


>
> (I'll ignore the proprietary vmware thing in what follows.)
>
>> virtualbox 4.2 will now install, compile & insert kernel modules
>
> Nice to read!
>
>> https://www.virtualbox.org/wiki/Linux_Downloads is verified by verisign,
>> so you only get verisign/ssl-level security
>
> A long-term solution for Tails would have to be based on Debian,
> rather than on Oracle's packages. Current status in Tails is a bit
> kludgy: we are shipping a 4.1.10-dfsg-1~bpo60+1 custom backport of the
> guest tools and drivers (custom because they are built against the
> xorg from squeeze-backports).


I retested the steps to install virtualbox using only debian packages,
this is what I came up with:


>From within tails-livecd 0.14 rc1, as root, over tor, in this order:
# apt-get update
# apt-get intall gcc
# ln -s /usr/bin/gcc-4.4 /usr/bin/gcc-4.6
# apt-get install make
# apt-get install linux-headers-3.2.0-4-686-pae
# apt-get install virtualbox-dkms
# apt-get install virtualbox-qt


^Now virtual box is installed & works, kernel modules compiled & inserted,
and a link in the Applications menu is installed to the virtualbox
graphical frontend


After apt-get install virtualbox-dkms, apt-get showed:
Get:1 http://backports.debian.org/debian-backports/ squeeze-backports/main
virtualbox i386 4.0.10-dfsg-1~bpo60+1 [15.0 MB]

So it appears to use backports for the virtualbox host binaries
version 4.0.10-dfsg-1~bpo60+1


>we are shipping a 4.1.10-dfsg-1~bpo60+1 custom backport of the guest tools
Good to know, can this present any problems with shipping the virtualbox
host binaries? It looks all compatible to me



>
>> TODO:
>> 1. Calculate what size requirements there would be if virtualbox was
>> ever
>> shipped with tails
>> 2. See how a git patch could be made that is easy simple and just makes
>> everything work well
>
> + check that issue, quoted directly from the aforementioned ticket:

Ballpark 20MB on the tracking webpage
https://tails.boum.org/todo/add_virtualbox_host_software/ so not too much


>
>   IIRC, VirtualBox host software sets iptables/netfilter up in a way
>   that makes the guest system bypass the existing firewall / or be
>   blocked by it, so some care should be taken on this side.

One idea is to use host-only networking in the virtualbox guest, and the
apps in the guest can connect to appropriate socks-port(s) on the hosts
host-only adapter



Bridge mode is the problem, it would be worth checking if the amnesia user
can leverage the virtualbox bridge kernel module/driver to bypass tor.
This would violate tails design because currently the amnesia user is not
allowed direct internet access.

Bridge mode and NAT support could simply be left out alltogether from
tails, any drivers deleted/not-installed

If the kernel modules for bridge and NAT adapters is left out of tails,
that would leave only the host-only networking adapter.

That leaves problems for users who have legitimate reasons to use bridge
or NAT mode (like me).




>
>> What does everyone think about virtualization and tails?
>
> Personally, I'd be very happy to see todo/add_virtualbox_host_software
> solved, but I lack time to do it any time soon. You are most welcome
> to go on working on this! :)

I'll do what I can and continue working on this. Unfortunately after
looking at it, it appears creating a git patch/branch that implements all
this is beyond my current skill level. I'll do what work on this I'm able
to do however :)

___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Tails Attack Surface Reduction - Bridge Enforcement

[adev]

> Hi,
>
> (meta: do you read the list of shall we Cc: you?)

I have recently subscribed to the list


>
> a...@riseup.net wrote (26 Oct 2012 18:23:29 GMT) :
>> The attack surface for revealing a users IP is now reduced to being
>> able to exploit a vulnerability in iptables, these are *extremely*
>> rare compared to vulnerabilities in the end-user applications used,
>> local kernel exploits etc
>
> FWIW, I think this is related to
>
>   * https://tails.boum.org/todo/Two-layered_virtualized_system/
>   * Whonix design
>
> This looks all interesting and valuable,
> but right now, we clearly don't have time to tackle it seriously.
> See https://tails.boum.org/contribute/roadmap/ for our priorities.
> Help is welcome.
>
> Cheers!
>

I'll do what I can :)

___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Tails 0.14 rc1 virtualization testing & howto install virtualbox and vmplayer

[adev]

> I did this from a fresh Tails session:
>
> sudo ln -s /usr/bin/gcc-4.4 /usr/bin/gcc-4.6
> sudo apt-get update
> sudo apt-get install --yes linux-headers-686-pae virtualbox-dkms \
> virtualbox-qt
> vboxmanage createvm --name Tails --ostype Debian --register
> vboxmanage modifyvm Tails --memory 1024
> vboxmanage storagectl Tails --name SATA0 --add sata \
> --controller IntelAHCI
> vboxmanage storageattach Tails --storagectl SATA0 --port 0 \
> --device 0 --type dvddrive --medium host:/dev/cdrom
> vboxmanage startvm Tails
>
> And then Tails starts as a guest within Tails, using the same boot
> media (there's no need to copy in the image to ram like you did).

This would be great for Tails as we can use vboxmanage to modify the
virtual tails as needed. I dont see Tails copying any ISO or filesystem
into RAM anytime soon (and booting the VM from that), it does have high
performance though compared to using the CD but really isnt necessary?


> Actually the Tails host I did this from was itself a VirtualBox guest,
> so it also shows that nested VMs work, but the nested-guest is slooow.

How slow? Unusably slow? Would Tails need to do something different to
ship a virtualized tails solution?

I havent tested using virtual tails from the same mechanical optical disk
yet.





>> * Allows stronger enforcement of tor-only connections, an attacker must
>> break out of a virtual machine, in addition to previous steps taken. A
>> VM
>> can be configured to only be able to send traffic through the tor
>> process
>> running on the host machine.
>
> Sure, but to configure the applications in the guest to use the host's
> Tor is non-trivial for most users (and would require us to make Tor's
> ports listen on more than localhost). I'd like a way so a whole VM is
> Torified without additional configuration inside the VM. Here's some an
> article one can find inspiration from:
>
> 

I can see the low effort maintainability goal, and it could be quicker and
easier to ship a virtualized tails that virtualises the entire VM, and
maybe think about individual app & firewall configuration later

However I do note that currently the firewall has per application rules,
and some apps have stream isolation, how much work would it be to have a
slightly different firewall configuration, and tell the apps to use the
same socks port, but vbox.guest.hostadapter.ip instead of localhost?

It would also need the bootmagic to be able to control which firewall
script gets loaded




>> * Enables the features described at
>> https://tails.boum.org/todo/Two-layered_virtualized_system/
>
> Needless to say, including Virtualbox host software in Tails is only a
> small step on the way to the above. There's still a lot of work left to
> achieve it in a user-friendly way (i.e. zero user configuration).

Yes a small step along the way. A shipped virtualbox might get more people
to start testing virtualization in tails.


I see some use cases here:

(1) User wants an entire $any VM to be torified, this VM is not
necessarily tails. They load they VM and the entire VM is torified through
one socks port. Then they can run their $random windows app


(2) Tails livecd IS the guest VM. Existing apps have exactly the same
stream isolation because the tails guest apps are preconfigured to connect
to vboxguest.hostadapter.ip:socksport

This does seem like alot of work, getting all the DNS reconfigured,
virtual tails does look like it has alot of issues to be ironed out



> One interesting thing to note, though, is that the host can start
> several guests using the same boot media in the way I described above.
> Hence we could add some kind of hook during Tails' boot process that,
> depending on some "magic" parameter set by the host (if any), makes
> Tails boot into specialized profiles (e.g. one that only runs Tor and
> one that runs the GUI stuff). For instance:
>
> * tor-guest: Boot Tails into a minimal mode (no Xorg etc.) that just:
>   - starts Tor with all its ports listening on the network.
>   - sets an appropriate firewall (only allow inbound traffic from the
> 'app-guest' vm (see below) to Tor's ports, and only the outbound
> traffic made by Tor).
> * i2p-guest: Same as 'tor-guest' but adapted for i2p.
> * app-guest: Boot Tails exactly like it's done now except:
>   - it uses the Tor instance running on 'tor-guest' vm.
>   - sets an appropriate firewall (only allow connections to the
>'tor-guest' and 'i2p-guest' vms)
Like!


>
> If no such profile is set Tails boots normally. In Tails Greeter we add
> an option called "Use isolation through virtualization" (or similar)
> that when set:
>
> 1. Continues from Tails Greeter to a simple X screen (no GNOME etc.
>running; only vms are supposed to be run from the host from now on).
> 2. Starts a Tails guest with th

Re: [Tails-dev] Tails 0.14 rc1 virtualization testing & howto install virtualbox and vmplayer

[adev]

> Having the regular tails.iso and a virtual machine image inside the
> tails.iso would be a lot redundancy.

Yes excessively redundant for a shipped tails product

It was nice though to see the incredible speed of a vmplayer virtual
machine with the tails iso stored in RAM, virtualbox didnt seem as fast
for some reason


___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Tails 0.14 rc1 virtualization testing & howto install virtualbox and vmplayer

[adev]

> anonym:
>>> * Allows stronger enforcement of tor-only connections, an attacker must
>>> > break out of a virtual machine, in addition to previous steps taken.
>>> A VM
>>> > can be configured to only be able to send traffic through the tor
>>> process
>>> > running on the host machine.
>> Sure, but to configure the applications in the guest to use the host's
>> Tor is non-trivial for most users (and would require us to make Tor's
>> ports listen on more than localhost). I'd like a way so a whole VM is
>> Torified without additional configuration inside the VM. Here's some an
>> article one can find inspiration from:
>>
>> 
>>
>> (Added to the todo item)
>>
>
> What about identity corelation since all VM traffic would go through a
> single Tor socks port?
> (Added to the todo item)
> ___
> tails-dev mailing list
> tails-dev@boum.org
> https://mailman.boum.org/listinfo/tails-dev
>


My thoughts on this are that I am in favor of apps not being network aware
unless being specifically configured to be so

Eg using host-only networking for the virtual machines network card, and
then configuring specific apps in the virtual machine to connect to a
socks port on the tails-livecd-host host-only network adapter

The livecd tor would need to listen on various socks ports (for stream
isolation) on the virtualbox host-only host network adapter

A well thought out firewall policy would be needed.


Yes this would be more work than simply saying "torify the whole VM" but
it does have its advantages:

* Existing strategy of stream isolation is preserved, as virtual apps can
still have isolated streams by connecting to a dedicated socks port

* Sometimes apps misbehave, or you install an app and it goes to
auto-update itself before you can tell it not too, but it has an insecure
update mechanism, if the whole VM is torified it would insecurely update
over tor.

If apps only work with Tor because the software came preconfigured, we get
greater control over which apps can communicate with the network or not

* Its not really that hard to tell the host tor to listen on socks ports
on an additional host-only network adapter, and telling the virtual apps
to use a socks-ports on the virtual hostonly adapter is much the same as
how existing apps are configured



Thoughts?
















___
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

[adev]

> Tails gets 9 fonts out of 33.
> TBB gets 33 fonts out of 33, even though some of them are not installed
> on the system.
>
> My question is does this difference in behavior make sense? Can it be
> related to any existing TBB patch?
>


Regarding browser fingerprinting, a number of years ago I used TBB
on EFFs panopticlick (with javascript disabled) and 1 in 3 browsers had my
fingerprint, current panopticlick shows my fingerprint as 1 in ~900 (0.14
rc1)



___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] tordate issue in Tails 0.14~rc1

[intrigeri]

anonym wrote (25 Oct 2012 17:05:41 GMT) :
> Personally I believe it's about the best we can do for now. Please merge.

Done.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

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

[intrigeri]

anonym wrote (29 Oct 2012 15:09:13 GMT) :
> After some initial problems I figured out that feature suites are
> named "feature-..." and not "feature/..." like our git branches.
> I could update the docs to reflect this, but I was first gonna
> propose that we make the tails-merge-suite script convert
> "feature/..." to "feature-..." to prevent future
> confusion. Thoughts?

Sure. The branch-to-suite name conversion code is already somewhere in
the Puppet module. Could probably be re-used :)

>>   3. Build an ISO image from testing, and check it gets the right
>>  iceweasel in the end.

> Works.

Perfect!

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

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

[anonym]

29/10/12 15:35, intrigeri wrote:
> anonym wrote (29 Oct 2012 13:04:07 GMT) :
>> However, esr10 is out: [...] But do we want it in rc2 too? After all
>> one of the purposes to ship an rc2 was to test the new Iceweasel.
>> Because of that I'm leaning towards delaying rc2 a few days if we
>> can have an updated package built and uploaded within that period.
> 
> Currently, we cannot easily build and updated package yet: I've just
> asked Mike Hommey to push his esr/master Git branch online. In any
> case, I doubt I'll be able to prepare and upload updated packages
> before Wednesday evening CEST, more probably Thursday.
> 
> So the question is whether we want to give a few more testing days to:
> 
>  (A) the diff between an unpatched iceweasel
>  and the new iceweasel + torbrowser one
> 
> or to:
> 
>  (B) the (I guess) tiny 10.0.9..10.0.10 diff
>  (FWIW, the TorBrowser patches did not need any update in between.)
> 
> I think the first one is the biggest and riskiest change, so my answer
> is clearly (A). So, IMHO let's put the RC2 out ASAP (I'll test and
> merge the updated tordate thing within 2 hours).

Let's go with A then, and hope that esr10 doesn't case problems in the
final 0.14 release. I'll release rc2 later today.

Cheers!

___
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

[anonym]

29/10/12 09:06, intrigeri wrote:
> anonym wrote (28 Oct 2012 20:35:14 GMT) :
>> I haven't found any issues at all, so I say merge.
> 
> Great. Would you please try to do it yourself, so that it helps
> ensuring that the Git + APT merge process works fine even when *I* am
> not the one who runs it?

A great idea.

> Basically:
> 
>   1. Merge the feature/torbrowser Git branch into the testing and
>  devel ones.

Done.

>   2. "Merge" the feature-torbrowser APT suite into the testing and
>  devel ones:
>  a. Add your SSH pubkey to the "reprepro" user's
> ~/.ssh/authorized_keys on "autobuild".
>  b. Proceed as documented on the APT repository ticket [1]
> ("Workflow" section, "Merging a topic branch" subsection).

After some initial problems I figured out that feature suites are named
"feature-..." and not "feature/..." like our git branches. I could
update the docs to reflect this, but I was first gonna propose that we
make the tails-merge-suite script convert "feature/..." to "feature-..."
to prevent future confusion. Thoughts?

>  c. Make sure it has worked:
> ssh repre...@incoming.deb.tails.boum.org reprepro ls iceweasel

Check.

>   3. Build an ISO image from testing, and check it gets the right
>  iceweasel in the end.

Works.


___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

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

[intrigeri]

sajol...@pimienta.org wrote (29 Oct 2012 13:09:25 GMT) :
> http://www.lalit.org/lab/javascript-css-font-detect/

> This one uses the technique described above to check for a set of 23
> common fonts.

> Tails gets 9 fonts out of 33.
> TBB gets 33 fonts out of 33, even though some of them are not installed
> on the system.

> My question is does this difference in behavior make sense?

Not to my eyes.

> Can it be related to any existing TBB patch?

I'm not sure I get the question right, because both pieces of software
under test are supposed to have the TorBrowser patches applied.

I skimmed over the only obviously font-related patch, and as far as
I understand it, it is not supposed to trigger such behaviour.

I also had a quick look to see if an iceweasel patch was about fonts,
and did not find any.

My next bet would be to compare TBB's and Tails' Firefox configuration.

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

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

[intrigeri]

anonym wrote (29 Oct 2012 13:04:07 GMT) :
> I have merged feature/torbrowser into testing, so it'll en up
> in rc2.

Great! I'm going to update the involved tickets.

> However, esr10 is out: [...] But do we want it in rc2 too? After all
> one of the purposes to ship an rc2 was to test the new Iceweasel.
> Because of that I'm leaning towards delaying rc2 a few days if we
> can have an updated package built and uploaded within that period.

Currently, we cannot easily build and updated package yet: I've just
asked Mike Hommey to push his esr/master Git branch online. In any
case, I doubt I'll be able to prepare and upload updated packages
before Wednesday evening CEST, more probably Thursday.

So the question is whether we want to give a few more testing days to:

 (A) the diff between an unpatched iceweasel
 and the new iceweasel + torbrowser one

or to:

 (B) the (I guess) tiny 10.0.9..10.0.10 diff
 (FWIW, the TorBrowser patches did not need any update in between.)

I think the first one is the biggest and riskiest change, so my answer
is clearly (A). So, IMHO let's put the RC2 out ASAP (I'll test and
merge the updated tordate thing within 2 hours).

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Tails 0.14 rc1 virtualization testing & howto install virtualbox and vmplayer

[intrigeri]

adrelanos wrote (29 Oct 2012 00:35:09 GMT) :
> intrigeri:
>> A long-term solution for Tails would have to be based on Debian,
>> rather than on Oracle's packages. Current status in Tails is a bit
>> kludgy: we are shipping a 4.1.10-dfsg-1~bpo60+1 custom backport of the
>> guest tools and drivers (custom because they are built against the
>> xorg from squeeze-backports).

> Probable once you switch to Wheezy to problem could vanish.

Yes... until we want to ship a newer xorg from wheezy-backports, in
order to support newer hardware :) When this will happen depends
entirely on the Debian X Strike Force time and energy, but I do hope
it will happen.

Anyway, it's quite easy to get the corresponding custom VirtualBox
*host* binary packages, built from the same source. Someone just has
to do it. This is merely a time / priorities problem, rather than
a serious technical one: I was mentionning the current state in
passing, as this knowledge will be needed to anyone who wants to push
this further the initial testing that started this thread.

> Wheezy has fine packages for Virtual Box (virtualbox) and Guest
> Additions (virtualbox-guest-x11).

> Would any any custom adjustments still be required?

No.

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

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

[intrigeri]

anonym wrote (28 Oct 2012 20:35:14 GMT) :
> I haven't found any issues at all, so I say merge.

Great. Would you please try to do it yourself, so that it helps
ensuring that the Git + APT merge process works fine even when *I* am
not the one who runs it?

Basically:

  1. Merge the feature/torbrowser Git branch into the testing and
 devel ones.

  2. "Merge" the feature-torbrowser APT suite into the testing and
 devel ones:
 a. Add your SSH pubkey to the "reprepro" user's
~/.ssh/authorized_keys on "autobuild".
 b. Proceed as documented on the APT repository ticket [1]
("Workflow" section, "Merging a topic branch" subsection).
 c. Make sure it has worked:
ssh repre...@incoming.deb.tails.boum.org reprepro ls iceweasel
 d. If something goes wrong, please send me the logs and
resulting output.

  3. Build an ISO image from testing, and check it gets the right
 iceweasel in the end.

[1] https://tails.boum.org/todo/APT_repository/

Cheers!
___
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

[sajolida]

On 27/10/12 16:22, Ague Mill wrote:
> 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. :)

I used that ISO while playing with browser fingerprint to compare Tails
0.14~rc2 and TBB 2.2.39-4. It worked fine.

The only difference I found (apart from the issue Ague discovered) is
about fonts detected using JavaScript.

Both Panopticlick and BrowserSpy only list fonts using Flash, so it is
not listing any font for neither Tails nor TBB. From what I understood,
there is no straight-forward technique to list available fonts using
JavaScript. The techniques I found rather check whether a given font is
available by comparing the graphical characteristics of a sample text
with the expected expected result with the original font.

Two of the tools I used showed differences between Tails and TBB:

http://ip-check.info/

I have no clue on how this number is calculated but it surely differs.
It also differs from the number of fonts returned for my non-torified
browser on the same system as the TBB.

Tails 0.14~rc2 gets 48 fonts installed.
TBB 2.2.39-4 gets 3 fonts installed.

http://www.lalit.org/lab/javascript-css-font-detect/

This one uses the technique described above to check for a set of 23
common fonts.

Tails gets 9 fonts out of 33.
TBB gets 33 fonts out of 33, even though some of them are not installed
on the system.

My question is does this difference in behavior make sense? Can it be
related to any existing TBB patch?



signature.asc
Description: OpenPGP digital signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

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

[anonym]

23/10/12 22:20, anonym wrote:
> 23/10/12 21:02, intrigeri wrote:
>> anonym wrote (23 Oct 2012 18:47:26 GMT) :
>>> Agreed. I think we may need a completely different release schedule
>>> than what we have now, which is:
>>
>>> October 25th: release of RC2.
>>> October 30th: release of 0.14.
>>
>>> Clearly this won't work if we do something drastic, which seems
>>> necessary. What about we bump RC2 until we have a fix for this
>>> (perhaps we should set a latest date?), and then release the final
>>> Tails 0.14 a week after that. That gives a few extra days for RC
>>> testers to find new issues with whatever solution we picked.
>>
>> Thanks for raising this topic. This proposal suits me well.
>>
>> FYI, on the iceweasel+torbrowser side of things, my plan is to
>> (hopefully) put a first test ISO out at some point before Thursday
>> 25th at noon CEST. Things are going well, and I think this is doable.
>> I'd like some of us (and as many people as possible, actually!) to
>> review and test it for a few days before we merge it and call that
>> RC2. So, I think best case is RC2 on Monday, 29th.

This is today.

>> Given another test
>> ISO will have been out for a few days already, we might dare releasing
>> 0.14 a bit less than a full week later. I'm happy to let this decision
>> up to whoever will actually do the release.
> 
> That would be me, and I'm ok with making such a decision.

I have merged feature/torbrowser into testing, so it'll en up in rc2.
However, esr10 is out:

http://packages.qa.debian.org/i/iceweasel/news/20121026T165314Z.html

So, what should we do? I think it's clear that we need to rebase our
Iceweasel on esr10 for the final release of Tails 0.14. But do we want
it in rc2 too? After all one of the purposes to ship an rc2 was to test
the new Iceweasel. Because of that I'm leaning towards delaying rc2 a
few days if we can have an updated package built and uploaded within
that period.

Cheers!

___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] Tails 0.14 rc1 virtualization testing & howto install virtualbox and vmplayer

[anonym]

29/10/12 01:30, adrelanos wrote:
> anonym:
>>> * Allows stronger enforcement of tor-only connections, an attacker must
 break out of a virtual machine, in addition to previous steps taken. A VM
 can be configured to only be able to send traffic through the tor process
 running on the host machine.
>> Sure, but to configure the applications in the guest to use the host's
>> Tor is non-trivial for most users (and would require us to make Tor's
>> ports listen on more than localhost). I'd like a way so a whole VM is
>> Torified without additional configuration inside the VM. Here's some an
>> article one can find inspiration from:
>>
>> 
>>
>> (Added to the todo item)
>>
> 
> What about identity corelation since all VM traffic would go through a
> single Tor socks port?

In this setup the VMs' traffic would be redirected to a dedicated Tor
TransPort via netfilter, so we could just set IsolateDestAddr on that
TransPort. It's perhaps not ideal, but I think I prefer that to
requiring users to make sane choices about which SocksPort:s to use.

Cheers!

___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev