Commit c2269abf authored by anonym's avatar anonym
Browse files

Merge branch 'stable' into devel

parents 0c4b34dd 9383ca77
This diff is collapsed.
......@@ -4,21 +4,17 @@ tails (3.0) UNRELEASED; urgency=medium
-- Tails developers <tails@boum.org> Fri, 07 Apr 2017 16:11:09 +0200
tails (2.12) UNRELEASED; urgency=medium
* Dummy entry.
-- Tails developers <tails@boum.org> Fri, 07 Apr 2017 13:55:00 +0200
tails (2.12~rc1) unstable; urgency=medium
tails (2.12) unstable; urgency=medium
* Major changes
- Completely remove I2P. :( We have decided to remove I2P (see
#11276) due to our failure of finding someone interested in
maintaining it in Tails (Closes: #12263).
- Upgrade the Linux kernel to 4.9.0-0.bpo.2 (Closes: #12122).
- Upgrade the Linux kernel to 4.9.13-1~bpo8+1 (Closes: #12122).
* Security fixes
- Upgrade Tor Browser to 6.5.2 based on Firefox 45.9. (Closes:
#12444)
- Mount a dedicated filesystem on /var/tmp, to mitigate the
hardlinks permissions open by the user-tmp abstraction. See
https://labs.riseup.net/code/issues/9949#note-23 for details
......@@ -31,6 +27,13 @@ tails (2.12~rc1) unstable; urgency=medium
repository. This has two problems. First, this results in unsafe
permissions on this file (e.g. a Vagrant build results in the
'amnesia' user having write access to it).
- Upgrade libjasper1 to 1.900.1-debian1-2.4+deb8u3
- Upgrade gstreamer and its plugins to 1.4.4-2+deb8u1.
- Upgrade eject to 2.1.5+deb1+cvs20081104-13.1+deb8u1.
- Upgrade imagemagick to 8:6.8.9.9-5+deb8u8.
- Upgrade pidgin to 2.11.0-0+deb8u2.
- Upgrade samba to 2:4.2.14+dfsg-0+deb8u5.
* Minor improvements
- Don't add the live user to the "audio" group. This should not be
......@@ -60,6 +63,7 @@ tails (2.12~rc1) unstable; urgency=medium
have `PrivateNetwork=yes` set.
- Get tor's bootstrap progress via GETINFO instead of log
grep:ing.
- Upgrade tor to 0.2.9.10-1~d80.jessie+1
* Bugfixes
- mirror-pool-dispatcher: bump maximum expected mirrors.json size
......@@ -78,6 +82,7 @@ tails (2.12~rc1) unstable; urgency=medium
by being more flexible when matching local packages in the apt
list file (Closes: #12374). Thanks to Arnaud <arnaud@preev.io>
for the patch!
- auto/build: support Stretch's GnuPG v2 keyring filename.
* Test suite
- Try possible fix for #11508. IPv6Packet:s' source is accessed by
......@@ -94,7 +99,7 @@ tails (2.12~rc1) unstable; urgency=medium
* Remove obsolete debug logging now that we don't log anything
interesting for `restart-tor` any more.
-- Tails developers <tails@boum.org> Thu, 06 Apr 2017 23:12:57 +0200
-- Tails developers <tails@boum.org> Tue, 18 Apr 2017 17:41:46 +0200
tails (2.11) unstable; urgency=medium
......
This is about [[!tails_ticket 10972]].
[[!toc levels=2]]
[[!toc levels=3]]
Related pages
=============
[[!map pages="blueprint/ARM_platforms/*"]]
Pros & cons
===========
......@@ -62,6 +67,14 @@ Pros & cons
Hardware
========
## Lists of devices
Useful, up-to-date lists of devices can be found there:
* [Developer Information for Chrome OS Devices](https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/)
* [Arch Linux ARM platform comparison](https://archlinuxarm.org/platforms/)
* [Arch Linux ARM downloads](https://archlinuxarm.org/about/downloads)
## CPU architecture
Current (mid-2014 to early 2016) ARM Chromebooks have one of:
......@@ -93,42 +106,95 @@ for armhf.
⇒ armhf should support all ARM Chromebooks for the foreseeable future.
**Update** one year later — April 2017, some ARMv8 (64-bit) ones have
appeared:
* [[!wikipedia MediaTek]] MT8173 ([[!wikipedia PowerVR]] GX6250 GPU),
e.g. in the Acer Chromebook R13 and Lenovo N23 Yoga Chromebook
* [Rockchip_RK3399](https://en.wikipedia.org/wiki/Rockchip#RK33xx_series)
([[!wikipedia Mali (GPU)]] T860 MP4 GPU), e.g. in the Samsung
Chromebook Plus
On the 32-bit front, a few RK3288-based tablets and media boxes keep
appearing, but the latest 32-bit ARM Chromebook was released in
2015-11.
## Drivers
Let's see how current Debian supports ARM Chromebooks.
### Debian
XXX
Let's see how current (early 2016) Debian supports ARM Chromebooks.
* Acer Chromebook 13 (CB5), Tegra K1
* Acer Chromebook 13 (CB5-311), Tegra K1
- [[!debwiki InstallingDebianOn/Acer/Chromebook_13_CB5-311-T8BT]]
suggests it may require a custom kernel
* Asus Chromebook C201, Rockchip RK3288
- [[!debwiki InstallingDebianOn/Asus/C201]]
suggests it may require a custom kernel
* Asus Chromebook Flip, Rockchip RK3288
* HP Chromebook 14 (some models), Tegra K1
Kali seems to provide one image per supported system
XXX: update this section with newer information, e.g. after
we've managed to boot a Debian kernel on an
[[Acer Chromebook R 13|ARM_platforms/Acer_Chromebook_R_13_CB5-312T]].
### How others handle it
Kali provides one image per supported system
([list of images](https://www.offensive-security.com/kali-linux-arm-images/),
[documentation](http://docs.kali.org/category/kali-on-arm)).
Their
[build scripts](https://github.com/offensive-security/kali-arm-build-scripts)
also display lots of machine-specific variations.
display lots of machine-specific variations, e.g. kernel version,
additional drivers and firmware, X.Org and ALSA configuration.
Arch Linux provides
[one image](https://archlinuxarm.org/about/downloads) per
[supported board](https://archlinuxarm.org/wiki/Platforms), and indeed
their installation instructions point to a different rootfs tarball,
each with a different kernel, e.g. the peach (ChromeOS 3.8 armv7h
kernel), veyron (ChromeOS 3.14 armv7h kernel), oak (ChromeOS 3.18
aarch64 kernel) ones. But they also have more generic images, e.g.
ARMv7 Multi-platform, ARMv7 Chromebook, and ARMv8 AArch64
Multi-platform ones, that ship with the mainline kernel and a bunch of
dtb files. It's not clear how doable it would be to create an image
that works well on devices that have different boards: including all
the needed dtb files seems easy, but is there a single (e.g. ChromeOS)
kernel version that has all the needed drivers and firmware?
The [Arch Linux ARM PKGBUILDs repository](https://github.com/archlinuxarm/PKGBUILDs)
have all their ARM-specific changes. In particular:
* <https://github.com/archlinuxarm/PKGBUILDs/tree/master/alarm>
has ARM-specific packages, mostly firmware, drivers and bootloaders
* <https://github.com/archlinuxarm/PKGBUILDs/tree/master/core/>
has the build information for various kernels (including `.its`
files, `mkimage` and `vbutil_kernel` command lines)
Bootloader
==========
## coreboot
## Chromebooks
On Chromebooks, one can "flash" a custom bootloader in the place where
the kernel would usually be found by the embedded bootloader.
This allows booting an OS in a more "traditional" way than what the
included bootloader requires, and brings a number of advantages, such
as: ability to edit the kernel command line, booting from external
storage without pressing CTRL+U (if that bootloader is installed on
the internal storage), bootloader menu (think "Troubleshooting Mode").
More information:
Ships in Chromebooks.
* <https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/custom-firmware>
* <https://www.chromium.org/chromium-os/firmware-porting-guide/using-nv-u-boot-on-the-samsung-arm-chromebook>
There's apparently a "legacy boot" mode that makes it "easy" to boot
another OS than ChromeOS. It is provided by the
[SeaBIOS](http://www.coreboot.org/SeaBIOS) payload of coreboot.
## Coreboot
## others?
Sadly, the "legacy boot" mode that makes it "easy" to boot another OS
than ChromeOS, thanks to the
[SeaBIOS](http://www.coreboot.org/SeaBIOS) payload of coreboot, is not
available on ARM.
XXX
XXX: is Coreboot or U-Boot installed on ARM Chromebooks?
<https://www.coreboot.org/Chromebooks> lists only X86 devices.
# Attempting to install Debian on a USB drive and boot it on a
# Chromebook R 13 CB5-312T-K7SP
# Resources:
# * https://wiki.debian.org/InstallingDebianOn/Asus/C201
# * https://wiki.debian.org/InstallingDebianOn/Acer/Chromebook_13_CB5-311-T8BT
# * https://wiki.debian.org/InstallingDebianOn/Samsung/ARMChromebook
# * https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/custom-firmware
# Interesting Debian packages:
# vboot-utils vboot-kernel-utils u-boot-tools
################################################################################
# Current status:
Both with the Chrome OS kernel and the Debian kernel approaches I end
up with something that fails in the exact same way: at the developer
mode start screen I press Ctrl+U, and then the display shuts down but
the computer remains running indefinitely. So it seems that an attempt
at booting actually happens; if the signing is messed up, or the
partitions don't look right, I should just get an error beep when
pressing Ctrl+U.
> This might be fixed by enabling the `DRM_MEDIATEK` Kconfig option,
> that's not enabled in Debian currently:
>
> * https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2e726dc4b4e2dd3ae3fe675f9d3af88a2d593ee1
> * https://lists.freedesktop.org/archives/dri-devel/2016-May/108049.html
>
> We should try enabling it in a custom kernel before requesting for
> these modules to be shipped in the Debian one.
################################################################################
# Do this on any Debian machine (does not have to be ARM):
DEV=/dev/sdb
ROOT_PART=${DEV}2
MNT=/mnt/debian
mkdir -p ${MNT}
# Partitioning the device:
parted --script ${DEV} mklabel gpt
cgpt create ${DEV}
# Below is for a 4 GiB USB drive, adjust if needed
# Too small for Debian's kernel + initrd:
#cgpt add -t kernel -l kernel -b 34 -s 32768 ${DEV}
#cgpt add -t data -l / -b 32802 -s 15325151 ${DEV}
# so let's double it:
cgpt add -t kernel -l kernel -b 34 -s 65536 ${DEV}
cgpt add -t data -l / -b 65570 -s 15292383 ${DEV}
blockdev --rereadpt ${DEV}
mkfs.ext4 ${ROOT_PART}
mount ${ROOT_PART} ${MNT}
debootstrap --arch=arm64 --foreign stretch ${MNT} http://ftp.de.debian.org/debian
# Unmount the filesystems:
umount ${MNT}
################################################################################
# From now on, everything happens on the Chromebook:
DEV=/dev/sda
ROOT_PART=${DEV}2
KERNEL_PART=${DEV}1
MNT=/mnt/debian
mkdir -p ${MNT}
# Unmount from wherever ChromeOS decided to auto-mount the device,
# remount where we want it:
umount ${ROOT_PART}
mount ${ROOT_PART} ${MNT}
# Complete the bootstrap:
chroot ${MNT} /debootstrap/debootstrap --second-stage
# Configure the system
cat > ${MNT}/etc/fstab <<EOF
${ROOT_PART} / ext4 errors=remount-ro 0 1
EOF
echo "chromian" > ${MNT}/etc/hostname
cp /etc/resolv.conf ${MNT}/etc/resolv.conf
chroot ${MNT} apt-get update
chroot ${MNT} apt-get install -y cgpt vboot-utils \
vboot-kernel-utils
chroot ${MNT} passwd -d root
# Kernel approach 1 - try the Chrome OS kernel
################################################################################
# Guess which kernel partition is the latest. Run cgpt show and see
# which one (KERN-A or KERN-B) has the highest priority.
cgpt show /dev/mmcblk0
# Copy the ChromeOS kernel to the root filesystem,
# In this example we'll assume it was KERN-B:
dd if=/dev/mmcblk0p4 of=${MNT}/boot/chromeos.kernel.signed
# Declare the kernel flags:
cat > ${MNT}/boot/kernel.flags <<EOF
console=tty1 printk.time=1 nosplash rootwait root=${ROOT_PART} ro rootfstype=ext4 lsm.module_locking=0
EOF
# Sign the kernel:
cat > ${MNT}/boot/sign-kernel.sh <<EOF
vbutil_kernel --repack /boot/vmlinuz.signed --keyblock \
/usr/share/vboot/devkeys/kernel.keyblock --version 1 \
--signprivate /usr/share/vboot/devkeys/kernel_data_key.vbprivk \
--config /boot/kernel.flags --oldblob /boot/chromeos.kernel.signed \
--arch arm
EOF
chroot ${MNT} sh /boot/sign-kernel.sh
# Write the signed kernel to the kernel partition:
dd if=${MNT}/boot/vmlinuz.signed of=${KERNEL_PART}
# Mark the newly written kernel partition as good and set the
# priority:
cgpt add -i 1 -S 1 -T 5 -P 12 ${DEV}
# Copy the ChromeOS kernel modules into the root filesystem:
mkdir -p ${MNT}/lib/modules
cp -r /lib/modules/* ${MNT}/lib/modules
# Copy the non-free firmware for the wifi device:
mkdir -p ${MNT}/lib/firmware/
cp -r /lib/firmware/* ${MNT}/lib/firmware
# Umount the filesystems:
umount ${MNT}
# DONE
# Kernel approach 2 - Debian's kernel
################################################################################
chroot ${MNT} apt install linux-image-arm64
# We need mt8173-evb.dtb but it's not present in Debian's kernel possibly due to:
# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833561
# so I got it from ubuntu xenial's (although I probably should compile myself):
# linux-image-4.8.0-34-generic_4.8.0-34.36-16.04.1_arm64.deb
# put it in ${MNT}/boot
# chroot into ${MNT}
cd /boot
cat > kernel-initrd.its <<EOF
/dts-v1/;
/ {
description = "Linux kernel image with one or more FDT blobs";
#address-cells = <1>;
images {
kernel@1{
description = "vmlinuz";
data = /incbin/("vmlinuz-4.9.0-2-arm64");
type = "kernel_noload";
arch = "arm";
os = "linux";
compression = "none";
hash@1{
algo = "sha1";
};
};
fdt@1{
description = "dtb";
data = /incbin/("mt8173-evb.dtb");
type = "flat_dt";
arch = "arm";
compression = "none";
hash@1{
algo = "sha1";
};
};
ramdisk@1{
description = "initrd.img";
data = /incbin/("initrd.img-4.9.0-2-arm64");
type = "ramdisk";
arch = "arm";
os = "linux";
compression = "none";
hash@1{
algo = "sha1";
};
};
};
configurations {
default = "conf@1";
conf@1{
kernel = "kernel@1";
fdt = "fdt@1";
ramdisk = "ramdisk@1";
};
};
};
EOF
mkimage -f kernel-initrd.its kernel-initrd.itb
echo "console=tty1 debug root=/dev/sda2 rw rootwait printk.time=1 nosplash lsm.module_locking=0" > cmdline
vbutil_kernel --pack vmlinuz.signed \
--keyblock /usr/share/vboot/devkeys/kernel.keyblock \
--version 1 \
--signprivate /usr/share/vboot/devkeys/kernel_data_key.vbprivk \
--config cmdline \
--bootloader cmdline \
--vmlinuz kernel-initrd.itb \
--arch arm
# Just for the record, here's a supposed alternative to above
# vbutil_kernel command but it seems to work worse (Ctrl+U at the
# Chrome OS developer mode boot screen behaves just as if it's not a
# valid device to boot from).
# futility --debug vbutil_kernel \
# --arch arm \
# --version 1 \
# --keyblock /usr/share/vboot/devkeys/kernel.keyblock \
# --signprivate /usr/share/vboot/devkeys/kernel_data_key.vbprivk \
# --bootloader cmdline \
# --config cmdline \
# --vmlinuz kernel-initrd.itb \
# --pack vmlinuz.signed \
# Install the kernel
dd if=vmlinuz.signed of=${DEV}
# Mark the newly written kernel partition as good and set the
# priority:
cgpt add -i 1 -S 1 -T 5 -P 12 ${DEV}
# DONE
......@@ -114,6 +114,7 @@ Running GUI applications in containers
- LWN on [An initial release of Flatpak portals for GNOME](https://lwn.net/Articles/694291/)
- [The flatpak security model – part 1: The basics](https://blogs.gnome.org/alexl/2017/01/18/the-flatpak-security-model-part-1-the-basics/)
- [The flatpak security model – part 2: Who needs sandboxing anyway?](https://blogs.gnome.org/alexl/2017/01/20/the-flatpak-security-model-part-2-who-needs-sandboxing-anyway/)
- [The flatpak security model, part 3 – The long game](https://blogs.gnome.org/alexl/2017/01/24/the-flatpak-security-model-part-3-the-long-game/)
* Ubuntu Snap
- LWN on [Snap interfaces for sandboxed applications](https://lwn.net/Articles/694757/),
comparing them to Flatpack's portals
......
......@@ -66,3 +66,4 @@ Options
Björksten <gustaf@accessnow.org>.
- https://www.bestpractical.com/docs/rt/4.2/RT/Crypt/GnuPG.html
- https://forge.puppetlabs.com/darin/rt
- Koumbit is using RT and told us about their experience in <ead91b4d-8a87-5855-de55-2c4ffcb40377@koumbit.org>
......@@ -15,11 +15,15 @@ We believe that privacy, the free exchange of ideas, and equal access to informa
## 2. Tails is and will remain free software
Equal access to information includes the free availability of our code and documentation as well as the transparency of our decision making processes. Tails will always be free to use, remix, adapt and distribute.
Equal access to information includes the free availability of our code and documentation as well as the transparency of our decision making processes.
All the components of Tails that we create ourselves are, and will be, licensed in a manner consistent with the [Debian Free Software Guidelines](https://www.debian.org/social_contract).
However, Tails includes a minor part of non-free firmware in order to work on as much hardware as possible.
Tails will always be free to use, remix, adapt and distribute.
As the only exceptions to this rule, Tails includes:
* a minor part of non-free firmware in order to work on as much hardware as possible;
* a few pieces of software whose source code is public but not compatible with the Debian Free Software Guidelines; they are needed to support important use cases.
## 3. We will give back to the Free Software community
......@@ -44,7 +48,7 @@ Mistakes sometimes happen. We will be honest about them and fix those that affec
Whenever severe security issues are reported to us in private, we will test them and ensure we promptly fix these issues. We will notify our users whenever such an issue has been reported to us. However, for the security of our users, we might not disclose such a severe issue before releasing a fix.
## 6. We are honest about the capabilities and limits of Tails and technologies it relies upon
## 6. We give users the means to decide how much they can rely on Tails
We encourage users to inform themselves and decide if Tails is suitable for their use case and how much they can trust it. We work diligently to keep our community up-to-date through our various communication channels about the current state of our software and its limitations. We encourage users to read our documentation as well as third-party documentation in order to make an informed decision and engage in a learning process about the tools we ship.
......
......@@ -10,3 +10,8 @@ and raises a number of questions about it.
Packaging](https://github.com/sipwise/kamailio-deb-jenkins):
glueing Jenkins, pbuilder, reprepro, jjb, nginx,
jenkins-debian-glue, piuparts, DEP-8, and more together.
- SuSE's [Open Build Service](http://openbuildservice.org/) is now
[[!debpts open-build-service desc="in Debian"]]. Resources relevant
to Debian package building:
- [Build a Debian package against Debian 8.0 using Download On Demand (DoD) service](http://nibbles.halon.org.uk/2016/10/build-a-debian-package-against-debian-8-0-using-download-on-demand-dod-service/)
- [Deploying OBS](https://suihkulokki.blogspot.com/2017/04/deploying-obs.html)
......@@ -6,11 +6,11 @@ We decided to call this option **Formats** which is how it is named in
*GNOME Settings* and close to how it is named in the
[Windows installer](https://edwardvbs.files.wordpress.com/2014/08/install1.png).
For example, the USA and Unite Kingdom, two English-speaking countries,
For example, the USA and United Kingdom, two English-speaking countries,
have different standards:
<table>
<tr><td></td><td>USA</td><td>England</td></tr>
<tr><td></td><td>USA</td><td>United Kingdom</td></tr>
<tr><td>Unit system</td><td>Imperial</td><td>Metric</td></tr>
<tr><td>Paper size</td><td>Letter</td><td>A4</td></tr>
<tr><td>Date & time</td><td>3/17/2017 3:56 PM</td><td>17/03/2017 15:56</td></tr>
......
......@@ -10,9 +10,11 @@ The email address of the interviewees are stored in the internal Git
repo: `contacts/intercept_interviews.mdwn`.
The names of the interviewees are changed but loosely related in terms
of gender, language, and age. For list of popular given names see
[[!wikipedia List_of_most_popular_given_names desc="Wikipedia: List of
most popular given names"]].
of gender, language, and age. For list of popular given names see:
- [[!wikipedia List_of_most_popular_given_names desc="Wikipedia: List of most popular given names"]]
- [[!wikipedia Category:English_male_given_names desc="Wikipedia: English male given names"]]
- [[!wikipedia Category:English_female_given_names desc="Wikipedia: English female given names"]]
[[!toc levels=2]]
......@@ -47,6 +49,8 @@ Interview script
- Would you give us your email if you want to keep in touch for future
questions or go deeper? Emails are stored encrypted and only
accessible to the core contributors.
- Do you know of anybody else using Tails and that would be worth
interviewing?
Template email for validating the output
----------------------------------------
......@@ -61,6 +65,165 @@ Template email for validating the output
Interviews
==========
<a id="margarita"></a>
Margarita, March 2017
---------------------
Margarita is a digital security consultant in Latin America. She used to
develop autonomous communication infrastructures and is now focusing on
training human-right defenders and organizations in digital security.
She has been presenting Tails mostly to two different public:
- Family members of missing people. For example working on building
lists of missing people and DNA databases. People often disappear
while traveling on roads and, as a consequence, people are sometimes
refraining from moving. So it's a challenge to transmit information
from one place to another or to be able to travel without carrying
sensitive information. For example, someone wanted to train people on
how to build a list of missing people in a community and decided to
travel to the community without a computer and only use Tails there.
- Women sharing abortion techniques and resources. They are often women
who cannot turn to their families to ask questions and look for
solutions and otherwise go and ask Google.
Things she likes:
- In the case of documenting missing people, they find the learning
curve worth it.
- It's portable: you keep it in your pocket and you don't have to
install anything else.
Things she dislikes:
- Tails became harder to boot on newer computers.
- In the case of women sharing abortion techniques, the learning curve
made it harder to adopt.
<a id="helen"></a>
Helen, March 2017
-----------------
Helen is a digital security trainer working in an organization defending
the right for free speech in North America and working with both large
news organizations and freelance journalists.
She uses Tails for her work, especially since some of the news
organizations they work with use *SecureDrop* to exchange files and
communicate with sources. These news organizations have dedicate
machines running Tails as their primary OS. She also uses Tails for
personal use several times a week. For example she always has a Tails
USB stick when she travels and doesn't want to carry her own equipment.
It's lighter and for example she can use the computer in the lobby of
her hotel or plug her Tails on the big TV screen in her room.
Things she likes:
- She likes the feeling of security. Tails allows her to keep her
regular computer (Ubuntu, Debian, or Mac depending on the day) — the
one where she stores her most important data — clean from phishing.
Tails is good for surfing around, gossiping, etc. It feels like the
early experience she had on the Internet when she was younger which
was free from worries. She actually prefers Tails to *Tor Browser* for
that kind of browsing.
- She uses Tails a lot for note taking (*gedit*, *LibreOffice*).
- She like *KeePassX* and going on IRC over Tails.
Things she dislikes:
- She doesn't like *Icedove* so much and would prefer using *mutt*.
- She is frustrated not to be able to save a custom background in Tails.
She feels like Tails is one of her computer and she likes to customize
her things.
- She likes the automatic upgrades in general but she always have to go
back to the documentation when the upgrade fails. As part of her work,
she also sometimes sees infrequent users struggling with accumulated
upgrades (for example upgrading from 2.6 to 2.10).
- She finds the Installation Assistant inferiorating for expert users
like her when she only wants to download the ISO. But she recognizes
that it otherwise works really well for new users.
- She wants a minesweeper game in Tails.
- Once she had troubles debugging a firewall from Tails because the
router was not giving a DHCP lease and the *Unsafe Browser* wouldn't
start without one.