Commit 5823e274 authored by anonym's avatar anonym
Browse files

Merge remote-tracking branch 'origin/master' into devel

parents 0cc76e0d 006c187b
# 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
......@@ -63,7 +63,8 @@ evaluate the idea of basing Tails on snapshots of Debian testing.
wrt. security vulnerabilities, as our 2.x channel is
* February 5 2017 — Debian Stretch freeze starts
* March 17-19th: fifth sprint (in-person, organized by intrigeri)
* XXX: sixth sprint (in-person? remote?)
* May 16-19: sixth sprint (remotely attended for everybody except
a couple of us)
* June 2017 (???) — Debian Stretch is released
* June-August 2017 — Tails 3.0 is released
......
......@@ -6,7 +6,7 @@ Issue number: [[!tails_ticket 11669]]
The Tails Social Contract is a set of commitments that we as contributors to the Tails project stand by. This work is derived from the Debian Social Contract and the Tor Social Contract. If you have any questions or comments, feel free to email: <tails-project@boum.org>.
This is a promise from our developer community to the rest of the world, affirming a commitment to our beliefs.
This is a promise from our contributors community to the rest of the world, affirming a commitment to our beliefs.
## 1. By creating Tails we try to provide usable tools for anonymity and privacy
......@@ -17,7 +17,7 @@ We believe that privacy, the free exchange of ideas, and equal access to informa
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.
All the components of Tails that we create ourselves are, and will be, licensed them in a manner consistent with the [Debian Free Software Guidelines](https://www.debian.org/social_contract).
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.
......@@ -36,13 +36,13 @@ As Tails is created in such a transparent manner, anyone is encouraged to partic
To make our community a welcoming place for everybody we agreed on a [[Code of Conduct|contribute/working_together/code_of_conduct]].
## 5. We will never harm our users intentionally.
## 5. We will never harm our users intentionally
We will always do our best to create secure and usable tools. We will never willingly include backdoors or malicious software nor will we cooperate with any entity wanting us to harm our users.
Mistakes sometimes happen. We will be honest about them and fix those that affect the safety of Tails users when they are reported to us.
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 immediately, before releasing a fix.
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
......
This page is meant to support
a [discussion on tails-ux](https://mailman.boum.org/pipermail/tails-ux/2017-February/003339.html) about the *Formats* setting.
[[!toc levels=1]]
1. Current implementation: "Formats" affects time/date formats
==============================================================
French user in japan with their own laptop:
<img src="https://labs.riseup.net/code/attachments/download/1536/formats-implemented-greeter-fr-jp.png" width="100%" height="auto" />
<img src="https://labs.riseup.net/code/attachments/download/1538/formats-implemented-session-fr-jp.png" width="100%" height="auto" />
French user in the USA using a local computer:
<img src="https://labs.riseup.net/code/attachments/download/1537/formats-implemented-greeter-fr-us.png" width="100%" height="auto" />
<img src="https://labs.riseup.net/code/attachments/download/1539/formats-implemented-session-fr-us.png" width="100%" height="auto" />
2. Current implementation but "Formats" does not affect time/date formats
=========================================================================
French user travelling in japan with their own laptop:
<img src="https://labs.riseup.net/code/attachments/download/1541/formats-nodate-greeter-fr-jp.png" width="100%" height="auto" />
<img src="https://labs.riseup.net/code/attachments/download/1540/formats-nodate-session-fr-jp.png" width="100%" height="auto" />
French user travelling in the USA using a local computer:
<img src="https://labs.riseup.net/code/attachments/download/1543/formats-nodate-greeter-fr-us.png" width="100%" height="auto" />
<img src="https://labs.riseup.net/code/attachments/download/1542/formats-nodate-session-fr-us.png" width="100%" height="auto" />
3. Current implementation but only allow "Formats" that match the chosen language
=================================================================================
UK user travelling in the US:
<img src="https://labs.riseup.net/code/attachments/download/1544/formats-language-greeter-en-gb-us.png" width="100%" height="auto" />
<img src="https://labs.riseup.net/code/attachments/download/1545/formats-language-greeter-en-gb-us-popoverok.png" width="100%" height="auto" />
<img src="https://labs.riseup.net/code/attachments/download/1547/formats-language-session-en-gb-us.png" width="100%" height="auto" />
4. Remove the "Formats" option entirely
=======================================
French user travelling in the USA using a local computer:
<img src="https://labs.riseup.net/code/attachments/download/1550/formats-remove-greeter-fr-us.png" width="100%" height="auto" />
<img src="https://labs.riseup.net/code/attachments/download/1549/formats-remove-session-fr-us.png" width="100%" height="auto" />
The **Formats** option allows users to choose which unit system (metric
or imperial), paper size, and date and time format to use according to
the standards in use in a territory.
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,
have different standards:
<table>
<tr><td></td><td>USA</td><td>England</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>
<tr><td>First day of the week</td><td>Sunday</td><td>Monday</td></tr>
</table>
We want to take into account people travelling or living in a territory
in which they prefer to have the interface in their own language rather
than the territory's language but want to use the local formats. *For
example, a Chinese person travelling to the US for business might prefer
Tails in Chinese but Sunday as the first day of the week to coordinate
with her clients.*
That's why we decided to have this option in the Greeter for more user control,
like configured usually in the installation of operating systems (like
[Debian](https://media.if-not-true-then-false.com/2012/08/03-debian-select-your-location-560x420.png)
and Windows).
Now, this flexibility can also lead to confusion. *For example, a French person
traveling to Japan for business might want Sunday as the first day of the week
to coordinate with her clients but might not be able to read the [names of the
days in Japanese](https://labs.riseup.net/code/attachments/download/1538/formats-implemented-session-fr-jp.png).*
In Windows, these problems are solved by having [very fine-grained
settings](https://labs.riseup.net/code/attachments/download/1568/French%20in%20the%20USA.png)
for each of the settings and allowing to change them in the session without
restarting.
Unfortunately, *GNOME Settings* doesn't have this:
- Formats can only be changed [all at once](https://labs.riseup.net/code/attachments/download/1570/GNOME%20all%20at%20once.png).
- Changing the formats requires [restarting](https://labs.riseup.net/code/attachments/download/1571/GNOME%20restart.png).
So, the confusion experienced by the French person choosing Japanese
formats cannot be corrected from inside the session in GNOME.
Still, we believe that:
- Having that flexibility is worth it and allowed by most other
operating systems.
- Tails is an operating that is meant to be restarted quite often
(let's say at least once a day), and in the rares scenarios where
explicitly setting a format leads to confusion:
- the confusion would be annoying but not critical
- the user would likely learn from her mistake and not set the format the next day.
Ideally, the limitations of *GNOME Settings* would not exist but as of
now we still prefer offering flexibility in the Greeter and a simple
model similar to the one of Windows and GNOME. Even if we are conscious that it
might lead to confusion in some cases, we prefer that to having no flexibility
or having a more complex model as discussed in [February
2017](https://mailman.boum.org/pipermail/tails-ux/2017-February/003339.html).
......@@ -9,6 +9,11 @@ quick questions that take no more than 10 to 15 minutes of dialogue.
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"]].
[[!toc levels=2]]
HOWTO
......@@ -53,8 +58,110 @@ Template email for validating the output
> documents on our website. Please correct me if I misunderstood
> something or if you want me to remove some bits.
Interviews
==========
<a id="adam"></a>
Adam, March 2017
----------------
Adam is an investigative journalist working in an organization raising
awareness around State surveillance and digital freedom in Western
Europe. He has been using lots of Tor in different environments for
years.
As part of his work, he uses Tails both fully amnesiac and with
persistence. He has dedicated hardware for running Tails: a modified
ThinkPad X60 with many parts removed and only minimal input and output
interfaces.
He uses Tails to create, edit, and sanitize sensitive documents before
sharing them with other people or publishing them. He doesn't want to
open these documents on his regular operating system. Sometimes he
doesn't use Tails for 3 months and then use it everyday during 1-2 weeks
to work on a specific story.
He also shares his secure machine with other people by his side to
review or edit these sensitive documents instead of having to send these
documents online. All-in-all he uses little Tor from Tails and use it
more for data isolation.
Maybe Qubes OS does more than Tails against exploits but Tails is a
cheaper and more practical way for him to create a secure machine: it's
cheaper hardware and has an easier learning curve. He also feels better
having a hardware isolation instead of the virtual isolation provided by
Qubes OS. When he wants no network activity on his X60 he unplugs the
Ethernet cable and that's it.
Things he likes:
- He trusts Tails because he knows personally some of the developers;
the same could apply to Debian.
- Tails has been around for a while and is widely uses. It is well
connected to the rest of the Tor community and has received more
exposure.
- He is used to Debian and feels comfortable hacking on the Debian base
of Tails when needed. He doesn't really know RPM and that's another
drawback of Qubes OS for him.
- He's happy to see *OnionShare* in Tails now.
Things he dislikes:
- His hardened X60 has a 32-bit processor and he won't be able to run
Tails 3.0 on it anymore.
- He finds it painful not to have the keyboard for his language listed
in the short list of keyboards in Tails Greeter.
- He had troubles trying to install additional packages in Tails and
instead reinstalled them every time. He wanted to use `scantailor`, a
post-processing tool for scanned pages, and `tesseract-ocr`, an
optical character recognition tool.
- He had troubles displaying local files in Tor Browser and thinks that
it's impossible to browser for anything under `file:///` in Tor
Browser.
- He had a hard time finding a direct download with the new Installation
Assistant: *"I want a nerd link!"*
<a id="alex"></a>
Alex, March 2017
----------------
Alex is a journalist working for a big news room in Western Europe.
She got an authorization from her network administrator to have two
machines at work: the official Windows machine from where she can access
the company's back office and her own machine running Debian and
sometimes Tails.
They have a partnership with a whistleblowing platform and when working
on their documents they do everything from Tails.
Things she likes:
- The fact that Tails is all-in-one. For example, she sometimes sets up
a Tails USB stick for a few colleagues in the "war room" while working
a sensitive paper and they have all they need to review and edit
documents or do some additional research.
- Qubes OS is a nice idea but Tails remains more straight-forward and
you can use it immediately. You can clone a new key for someone and
that's all they need.
- Tails Installer in Debian! For example it's super useful to manually
upgrade a relatively old version or to install a new USB stick for
someone without having to restart on Tails.
- The installation documentation is much better now.
Things she doesn't like:
- She misses a screen locker. For example, to have a break during long
working sessions while working on sensitive documents.
- GMail doesn't work with Icedove and TorBirdy. So you have to switch to
the Unsafe Browser to connect to GMail.
<a id="jeanne"></a>
Jeanne, February 2017
=====================
---------------------
Jeanne has been working as an independent journalist for 5-6 years. She
writes stories that she sells to many different newspapers. She is also
......
[[!toc levels=6]]
---
# Lista de e-mails
A tradução do Tails para português é organizada em uma lista de e-mails. O formulário de inscrição está lá embaixo no título "** Inscrevendo-se na lista tails-l10n-pt-br@boum.org **": <https://mailman.boum.org/listinfo/tails-l10n-pt-br>
---
# Fluxo de trabalho para tradução para o português
## Preparação
Antes de seguir o fluxo de trabalho, você precisa fazer o seguinte:
* Instale o `git` e o `poedit`.
* Escolha um diretório dentro do qual será armazenada uma cópia do repositório do Tails. Nas instruções a seguir, esse diretório é chamado `diretorio-base/`.
* Veja a [[documentação no site do tails sobre como traduzir usando repositórios git|/contribute/how/translate/with_Git/]] *(em inglês - ajude a traduzir!)*. As instruções dadas aqui são um pouco diferentes, principalmente no que se refere é submissão das modificações. Ao invés de utilizar um repositório remoto, nós utilizamos um arquivo com as diferenças e a lista de tradução para essa parte do trabalho.
* Se tiver qualquer dúvida, escreva para a lista!
## Fluxo
O fluxo de trabalho para tradução e submissão das alterações é o seguinte:
### Copiar repositório
Copie ou atualize o reposiório do Tails. Nos comandos, substitua diretorio-base/ pelo caminho para o diretório base escolhido.
Copie o repositório, caso ainda não possua uma cópia local:
cd diretorio-base/
git clone git://git.tails.boum.org/tails
cd tails/
Configure os meta-dados do git para anonimizacao da traducao
git config user.name "Tails developers"
git config user.email "tails@boum.org"
Atualize o repositório, caso já possua uma cópia local:
cd diretorio-base/tails
git checkout master
git pull origin master
### Crie um ramo de trabalho
Substitua `nome-do-ramo-de-trabalho` por algo significativo relacionado ao que você está traduzindo, por exemplo `atualizacao-da-documentacao`. O nome do ramo de trabalho não pode conter espaços.
git checkout -b nome-do-ramo-de-trabalho
### Traduza
Traduza arquivos com a extensão `.pt.po` usando [poedit](https://poedit.net/). Este editor está incluído no Tails por padrão.
### Teste
[[Gere os arquivos estáticos para testar as alterações|/contribute/build/website/]]. Se precisar consertar algo, volte para o ítem anterior.
### Salve
Congele uma versão do que foi alterado:
git commit -a -m "[l10n] [pt-br] succinct description of changes"
### Gerar patch
Gere um arquivo com as diferenças entre o ramo de trabalho e o ramo principal:
git format-patch master
O resultado desse comando é o nome de um arquivo que é gerado com as diferenças entre o seu ramo de trabalho e o ramo principal.
### Envie para a lista
Envie o arquivo gerado para a lista aguarde que as diferenças sejam revisadas e inseridas no ramo principal.
### Atualize