path: root/wiki/src/contribute
diff options
Diffstat (limited to 'wiki/src/contribute')
49 files changed, 1210 insertions, 467 deletions
diff --git a/wiki/src/contribute/APT_repository.mdwn b/wiki/src/contribute/APT_repository.mdwn
index 31375a6..0075232 100644
--- a/wiki/src/contribute/APT_repository.mdwn
+++ b/wiki/src/contribute/APT_repository.mdwn
@@ -16,7 +16,7 @@ We use one single APT repository hosting multiple *suites*:
* We have a suite for each *topic* branch: `bugfix/*`, `feature/*`.
**Important note**: the APT suite corresponding to a given Git topic
branch contains *only* the packages this branch adds to the tag or
- *main* branch it diverged from.
+ *main* branch it diverged from. Think of it as an overlay.
* We also have a less formal `unstable` suite, that should not be used
by any Tails git branch; it can be used as hosting space for other
packaging work we might do, e.g. acting as upstream or
@@ -55,8 +55,9 @@ The build system adds the relevant APT sources:
a matching tag exists), then add the suite corresponding to this
release (e.g. `0.10` or `0.10.1`);
* else, if building from the `testing` branch, add the `testing` suite
+* else, if building from the `devel` branch, add the `devel` suite
* else, if building from the `experimental` branch, add the `experimental` suite
-* else, if building from the `devel` branch, add its own suite
+* else, add the `devel` suite
Also, if we're building from a bugfix or feature branch, add its
own suite.
@@ -266,7 +267,7 @@ If you just put out a final release:
the next major release, so that
next builds from the `devel` branch do not use the APT suite meant
for the last release
-* increment the version number in devel's `debian/changelog` to match
+* increment the version number in stable's `debian/changelog` to match
the next point release, so that
next builds from the `stable` branch do not use the APT suite meant
for the last release
@@ -299,6 +300,6 @@ Contributing without privileged access
Non-core developers without access to the "private" APT infrastructure
would add the .deb they want to their Git branch as we have been
-doing until now, push the result on or whatever... and at
+doing until now, push the result on GitLab or whatever... and at
merge time, we would rewrite their history to remove the .deb, and
import it into our APT repo.
diff --git a/wiki/src/contribute/build.mdwn b/wiki/src/contribute/build.mdwn
index ebcb03f..6a5b43b 100644
--- a/wiki/src/contribute/build.mdwn
+++ b/wiki/src/contribute/build.mdwn
@@ -2,6 +2,13 @@
[[!toc levels=2]]
+Git repository and branches
+You will need to clone the Tails Git repository, and to checkout the
+branch that you want to build (most likely, _not_ `master`): learn
+more about [[our Git branches layout|contribute/git#main-repo]].
<a id="vagrant"></a>
Using Vagrant
@@ -94,7 +101,7 @@ Debian Wheezy and Jessie:
Once all dependencies are installed, get the Tails sources and
checkout the development branch:
- git clone git://
+ git clone
cd tails
git checkout devel
@@ -166,26 +173,6 @@ The following flags can be used to force a specific behaviour:
if a local HTTP proxy is set.
* **noproxy**: do not use any HTTP proxy.
-### Bootstrap cache settings
-A Tails build starts with `debootstrap`:ing a minimal Debian system
-which then is modified into a full Tails system. This is a rather time
-consuming step that usually does not have to be done: the packages used
-in it rarely get updated and hence the result is exactly the same most
-of the time.
-The following flags can be used to force a specific behaviour:
- * **cache**: re-use a cached bootstrap stage (if available), and saves
- the bootstrap stage to disk on successful build. This will also
- reduce the amount of memory required for in-memory builds by around
- 150 MiB (see the **ram** option above). **Warning:** this option may
- create subtle differences between builds from the exact same Tails
- source which are hard to track to track and understand. Use this
- option only if you know what you are doing, and if you are not
- building an actual release.
- * **nocache**: do the bootstrap stage from scratch (default).
### SquashFS compression settings
One of the most expensive operations when building Tails is the creation
@@ -204,7 +191,6 @@ Forcing a specific behaviour can be done using:
Some operations are preserved accross builds. Currently they are:
* The wiki (for documentation).
-* The bootstrap stage cache (see the **cache** option above).
In case you want to delete all these, the following option is available:
@@ -268,7 +254,8 @@ The following Debian packages need to be installed:
221F 9A3C 6FA3 E09E 182E 060B C798 8EA7 A358 D82E
-* `syslinux`
+* `syslinux-utils` 6.03, e.g. from our `builder-wheezy` repository
+ just like `live-build`
* `eatmydata`, `time` and `whois` (for `/usr/bin/mkpasswd`)
* `ikiwiki` 3.20120725 or newer, available in wheezy-backports.
* `apt-get install libyaml-perl libyaml-libyaml-perl po4a perlmagick
@@ -280,10 +267,8 @@ The following Debian packages need to be installed:
Configure live-build
-Add these lines to `/etc/live/build.conf`:
+Remove any line matching `/^[[:space:]]*LB.*MIRROR.*=/` in
Build process
diff --git a/wiki/src/contribute/calendar.mdwn b/wiki/src/contribute/calendar.mdwn
index 95efa93..d674b8b 100644
--- a/wiki/src/contribute/calendar.mdwn
+++ b/wiki/src/contribute/calendar.mdwn
@@ -1,35 +1,27 @@
[[!meta title="Calendar"]]
-* 2014-12-02:
- - TBB 4.x TBB 4.x based on Firefox 31.3.0esr is *hopefully* out
- (notice the [one week delay](!topic/
- for this Firefox release)
- - Tag 1.2.1 in Git
- - Build and upload 1.2.1 ISO and IUKs
-* 2014-12-03:
- - Test (early CEST) and release (late CEST) Tails 1.2.1
- - [[Monthly meeting|contribute/meetings]]
+* 2015-03-03: [[Monthly meeting|contribute/meetings]]
-* 2014-12-12: [[Low-hanging fruits session|contribute/low-hanging_fruit_sessions]]
+* 2015-03-12: [[Low-hanging fruits session|contribute/low-hanging_fruit_sessions]]
-* 2015-01-03: [[Monthly meeting|contribute/meetings]]
+* 2015-04-07: Release 1.3.1 (anonym is the RM)
-* 2015-01-12: [[Low-hanging fruits session|contribute/low-hanging_fruit_sessions]]
+* 2015-05-19: Release 1.4 (anonym is the RM)
-* 2015-01-14: Release 1.2.2. anonym is RM.
+* 2015-06-30: Release 1.4.1
+ - anonym is the RM until June 10
+ - intrigeri is the RM from June 10 to the release
-* 2015-02-03: [[Monthly meeting|contribute/meetings]]
+* 2015-08-11: Release 1.5
+ - intrigeri is the RM until July 20
+ - anonym is the RM from July 20 to the release
-* 2015-03-12: [[Low-hanging fruits session|contribute/low-hanging_fruit_sessions]]
+* 2015-09-22: Release 1.5.1 (anonym is the RM)
-* 2015-02-17: Release 1.3. Still undecided who will be RM, but anonym
- probably can do it.
+* 2015-11-03: Release 1.6 (anonym is the RM)
-* 2015-03-03: [[Monthly meeting|contribute/meetings]]
-* 2015-03-12: [[Low-hanging fruits session|contribute/low-hanging_fruit_sessions]]
+* 2015-12-22: Release 1.6.1 (anonym is the RM)
-* 2015-03-31: Release 1.3.1.
+* 2016-02-02: Release 1.7
-* 2015-05-15: Release 1.4.
+* 2016-03-15: Release 1.7.1
diff --git a/wiki/src/contribute/design.mdwn b/wiki/src/contribute/design.mdwn
index 49ec01f..1e37669 100644
--- a/wiki/src/contribute/design.mdwn
+++ b/wiki/src/contribute/design.mdwn
@@ -672,7 +672,7 @@ Critical parts of the configuration are based on the ones from
well-known and trusted sources, namely Tails ancestor
and the [Tor BrowserBundle](
-This is for example the case for the firewall, polipo and Tor configurations.
+This is for example the case for the firewall and Tor configurations.
**NOTICE**: this distribution is provided as-is with no warranty of
fitness for a particular purpose, including total anonymity. Anonymity
@@ -712,8 +712,6 @@ extension).
that the Debian distribution does not provide or endorse Tails.
- [Tor]( anonymizing overlay network for
TCP. Our intention is to always use the latest stable version.
-- [polipo](
- Caching web proxy.
- [Vidalia]( is used
to control Tor's behavior.
@@ -1203,6 +1201,40 @@ Tails has some minimal [[contribute/design/application_isolation]] to
mitigate a bit the consequences of security issues in individual
applications being exploited by attackers.
+### 3.6.26 wget
+We wrap `wget` with `torsocks`, after unsetting the `http_proxy`
+environment variable and friends, so that it talks directly to the Tor
+SOCKS port.
+- [[!tails_gitweb config/chroot_local-includes/usr/local/bin/wget]]
+### 3.6.27 APT
+During most of the ISO build process, APT uses the proxy configured
+through `live-build` (that is, usually a local `apt-cacher-ng`).
+However, at boot time, a hook does (a more elaborate version of)
+`s,http://,tor+http://` in APT sources. Then, APT will use the
+`tor+http` method, that is a simple torsocks wrapper for the good old
+`http` method.
+- [[!tails_gitweb config/chroot_local-includes/usr/lib/apt/methods/tor+http]]
+- [[!tails_gitweb config/chroot_local-includes/lib/live/config/1500-reconfigure-APT]]
+### 3.6.28 Electrum
+We install the [Electrum]( Bitcoin client and the
+default configuration tells it to use the default of Tor's
+SOCKSPort:s, and sync the necessary parts of the Bitcoin blockchain
+(as a lightweight client) from the default server pool using SSL.
+There is also a persistence preset for the live user's `.electrum`
+configuration folder, which stores the Bitcoin wallet, application
+preferences and the cached Bitcoin blockchain.
+- [[!tails_gitweb_dir config/chroot_local-includes/etc/skel/.electrum]]
## 3.7 Running Tails in virtual machines
### 3.7.1 Current support
diff --git a/wiki/src/contribute/design/I2P_Browser.mdwn b/wiki/src/contribute/design/I2P_Browser.mdwn
index 37e44ee..b2ad411 100644
--- a/wiki/src/contribute/design/I2P_Browser.mdwn
+++ b/wiki/src/contribute/design/I2P_Browser.mdwn
@@ -51,6 +51,8 @@ Code
* [[!tails_gitweb config/chroot_local-includes/usr/local/sbin/i2p-browser]]
+* [[!tails_gitweb config/chroot_local-includes/usr/local/lib/tails-shell-library/]]
+* [[!tails_gitweb config/chroot_local-includes/usr/local/lib/tails-shell-library/]]
* [[!tails_gitweb config/chroot_local-includes/usr/share/applications/]]
* [[!tails_gitweb chroot_local-includes/lib/live/config/2080-install-i2p]
* [[!tails_gitweb config/chroot_local-includes/usr/local/bin/tails-activate-win8-theme]]
diff --git a/wiki/src/contribute/design/Time_syncing.mdwn b/wiki/src/contribute/design/Time_syncing.mdwn
index ad1f59e..33ebbb0 100644
--- a/wiki/src/contribute/design/Time_syncing.mdwn
+++ b/wiki/src/contribute/design/Time_syncing.mdwn
@@ -24,16 +24,14 @@ using Tor so we can make Tor usable.
In short this is how time syncing is performed when Tails starts:
0. Start Tor. If Tor is already working, skip to HTP step.
-0. Let Tor fetch a consensus (wait 150 seconds twice, restarting Tor
+0. Let Tor fetch a consensus (wait up to 150 seconds twice, restarting Tor
in between).
0. If the time is too badly off, the authority certificate may not be
- valid any more, so we set the system time to the Tails release date, which
- will guarantee that the certificates are valid. Then we SIGHUP Tor
- and wait for a new consensus again.
-0. Set the system time to an initial "guess" based on the Tor
- consensus validity period, no matter if the consensus was verifiable
- or not.
-0. Restart Tor, which now should be working.
+ valid, so we set the system time to the `valid-after` of the unverified
+ consensus Tor fetched for us, which will guarantee that the certificate
+ and consensus are all valid. Then we restart Tor (since it behaves badly
+ with time jumps during the early bootstrap stages) and wait until it
+ accepts the consensus and finishes the bootstrap.
0. Run HTP (see below) through Tor to get a more correct system time.
A notification is shown while the whole process is running,
@@ -127,7 +125,7 @@ custom version of the Perl HTP client into
[[!tails_gitweb config/chroot_local-includes/usr/local/sbin/htpdate]].
The repository we copied this script from can be found there:
- git://
For reasons detailed bellow, this version of htpdate uses curl for all
of its HTTP operations.
diff --git a/wiki/src/contribute/design/Tor_enforcement.mdwn b/wiki/src/contribute/design/Tor_enforcement.mdwn
index 33bcab9..d13db74 100644
--- a/wiki/src/contribute/design/Tor_enforcement.mdwn
+++ b/wiki/src/contribute/design/Tor_enforcement.mdwn
@@ -10,11 +10,6 @@ DNS
[[!inline pages="contribute/design/Tor_enforcement/DNS" raw=yes]]
-HTTP Proxy
-[[!inline pages="contribute/design/Tor_enforcement/Proxy" raw=yes]]
Network filter
diff --git a/wiki/src/contribute/design/Tor_enforcement/Network_filter.mdwn b/wiki/src/contribute/design/Tor_enforcement/Network_filter.mdwn
index 33c4226..3c067ad 100644
--- a/wiki/src/contribute/design/Tor_enforcement/Network_filter.mdwn
+++ b/wiki/src/contribute/design/Tor_enforcement/Network_filter.mdwn
@@ -1,6 +1,6 @@
One serious security issue is that we don't know what software will
attempt to contact the network and whether their proxy settings are
-set up to use the Tor SOCKS proxy or polipo HTTP(s) proxy correctly.
+set up to use the Tor SOCKS proxy correctly.
This is solved by blocking all outbound Internet traffic except Tor
(and I2P when enabled), and explicitly configure all applications to use either of
diff --git a/wiki/src/contribute/design/Tor_enforcement/Proxy.mdwn b/wiki/src/contribute/design/Tor_enforcement/Proxy.mdwn
deleted file mode 100644
index 7389363..0000000
--- a/wiki/src/contribute/design/Tor_enforcement/Proxy.mdwn
+++ /dev/null
@@ -1,10 +0,0 @@
-Polipo provides with caching HTTP proxy functionality. It contacts the
-Tor software via SOCKS5 to make the real connections: [[!tails_gitweb
-In case the firewall is buggy or not properly started, proxy settings
-are used as part of a defence in depth strategy:
-- The standard `http_proxy` and `HTTP_PROXY` environment variables are
- globally set in [[!tails_gitweb
- config/chroot_local-includes/etc/environment]] to point to Polipo.
diff --git a/wiki/src/contribute/design/UEFI.mdwn b/wiki/src/contribute/design/UEFI.mdwn
index c6b587b..9ecd88f 100644
--- a/wiki/src/contribute/design/UEFI.mdwn
+++ b/wiki/src/contribute/design/UEFI.mdwn
@@ -30,8 +30,8 @@ Non-goals
in Legacy BIOS boot mode from hybrid ISO cat'd on a USB device.
If the firmware supports it, this can be done on the same computer;
else, from another computer.
-* 32-bit UEFI boot: this hardware is rare and mostly obsolete these
- days
+* 32-bit UEFI boot: this hardware is rare; we have [[!tails_ticket
+ 8471 desc="plans to reconsider this decision"]], though.
* [[blueprint/UEFI Secure boot]] is not part of this plan.
Picking technical solutions that leave room for it would be a great
bonus, though.
diff --git a/wiki/src/contribute/design/Unsafe_Browser.mdwn b/wiki/src/contribute/design/Unsafe_Browser.mdwn
index 6eae7d6..412eded 100644
--- a/wiki/src/contribute/design/Unsafe_Browser.mdwn
+++ b/wiki/src/contribute/design/Unsafe_Browser.mdwn
@@ -83,6 +83,7 @@ Code
* [[!tails_gitweb config/chroot_local-includes/usr/local/sbin/unsafe-browser]]
+* [[!tails_gitweb config/chroot_local-includes/usr/local/lib/tails-shell-library/]]
* [[!tails_gitweb config/chroot_local-includes/usr/share/applications/]]
* [[!tails_gitweb config/chroot_local-includes/etc/sudoers.d/zzz_unsafe-browser]]
* [[!tails_gitweb config/chroot_local-includes/usr/local/bin/tails-activate-win8-theme]]
diff --git a/wiki/src/contribute/design/application_isolation.mdwn b/wiki/src/contribute/design/application_isolation.mdwn
index 1c9b5b7..8595da0 100644
--- a/wiki/src/contribute/design/application_isolation.mdwn
+++ b/wiki/src/contribute/design/application_isolation.mdwn
@@ -37,7 +37,10 @@ The AppArmor confinement profiles included in Tails come from:
* individual Debian packages that ship confinement profiles, e.g.
Tor and Vidalia;
* the [[!debpts apparmor-profiles]] package;
-* the [[!debpts apparmor-profiles-extra]] package.
+* the [[!debpts apparmor-profiles-extra]] package;
+* the [[!debpts torbrowser-launcher]] package:
+ - [[!tails_gitweb config/chroot_local-includes/usr/share/tails/torbrowser-AppArmor-profile.patch]]
+ - [[!tails_gitweb config/chroot_local-hooks/19-install-tor-browser-AppArmor-profile]]
To get the full and current list, run `aa-status` as `root`
inside Tails.
@@ -59,11 +62,85 @@ that are actually seen by AppArmor in the context of Tails:
* [[!tails_gitweb config/chroot_local-patches/apparmor-adjust-home-tunable.diff]]
* [[!tails_gitweb config/chroot_local-patches/apparmor-adjust-tor-profile.diff]]
+* [[!tails_gitweb config/chroot_local-patches/apparmor-adjust-totem-profile.diff]]
* [[!tails_gitweb config/chroot_local-patches/apparmor-adjust-user-tmp-abstraction.diff]]
Below, we discuss various leads that might avoid the need for coming
up with such adjustments, and maintaining it.
+<a id="ux"></a>
+User experience matters
+Currently, no good way exists to let the user choose an arbitrary file
+each time they want to open or save one, without leaving the AppArmor
+profiles wide-open and then much less useful.
+Solutions to this problem are work-in-progress in various upstream
+places (e.g. AppArmor and GNOME sandboxed applications). The idea is
+generally to introduce a privileged mediation layer between
+applications, the GTK file chooser and the filesystem. So, some day we
+can solve this problem in better ways, but we're not there yet.
+Tor Browser
+As of Tails 1.3, the Tor Browser is somewhat confined with AppArmor.
+Given we cannot seriously allow the Tor Browser to read and write
+everywhere in the home and persistent directory, we had to allow it to
+read/write files from/to one specific directory, and make it so the
+user experience is not hurt too much.
+Now, let's say we have a downloads/uploads directory that's shared
+between the Tor Browser, the file browser, and all non-confined
+applications. That directory is called `~/Tor Browser/`, and a GTK
+bookmark pointing to it is created at login time:
+* [[!tails_gitweb config/chroot_local-includes/etc/xdg/autostart/create-tor-browser-directories.desktop]]
+* [[!tails_gitweb config/chroot_local-includes/usr/local/lib/create-tor-browser-directories]]
+* [[!tails_gitweb config/chroot_local-includes/etc/xdg/autostart/add-GNOME-bookmarks.desktop]]
+* [[!tails_gitweb config/chroot_local-includes/usr/local/lib/add-GNOME-bookmarks]]
+Then, we have a usability issue: the space available in that directory
+is limited by the free system memory (RAM). So large file downloads
+may fail. Note that Firefox doesn't mind letting users start
+downloading a file to a directory that hasn't enough room available to
+store it entirely, so this problem is not specific to downloading to
+an amnesiac directory.
+Still, we thought it would be good to allow users to download large
+files from Tor Browser to their persistent volume, so we have
+introduced a second downloads/uploads directory: `~/Persistent/Tor
+Browser/`, that is created whenever the "Personal data" (aka.
+`~/Persistent/`) persistence feature is activated. In that case, if
+persistence was activated read-write, another GTK bookmark pointing to
+that directory is created at login time.
+This seemed to be better than introducing yet another persistence
+feature (e.g. for `~/Tor Browser/`): having downloads be either always
+amnesiac or always persistent (unless you restart or do stuff outside
+of the browser) would seem like a regression, since it breaks one of
+the core Tails properties. And forcing it to be a persistent folder by
+default actually has security issues since secure deletion does not
+work as expected on Flash memory. So, we decided that users need to
+have the option to download either to an amnesiac (`~/Tor Browser/`)
+or persistent (`~/Persistent/Tor Browser/`) place, like it was the
+case previously.
+So, in a nutshell we give Tor Browser access to:
+* `~/Tor Browser/`, which is amnesiac, as everything else in Tails by
+ default; this is set to be the default download directory
+ ([[!tails_gitweb config/chroot_local-includes/etc/tor-browser/profile/preferences/0000tails.js]]);
+* `~/Persistent/Tor Browser/`, that is persistent, and only created
+ when `~/Persistent/` is itself persistent and read-write.
+Note that we don't call these folders "Downloads", because e.g.
+if someone creates an ODT file and wants to upload it, having to move
+it to a folder called "Downloads" sounds really weird.
Future work
diff --git a/wiki/src/contribute/design/hybrid_ISO.mdwn b/wiki/src/contribute/design/hybrid_ISO.mdwn
index 6fa0a5f..554143e 100644
--- a/wiki/src/contribute/design/hybrid_ISO.mdwn
+++ b/wiki/src/contribute/design/hybrid_ISO.mdwn
@@ -1,10 +1,22 @@
Since 0.5 up to 0.10.2, every published Tails i386 ISO image has been a hybrid one:
-- it can be burnt to a CD;
+- it can be burnt to a DVD;
- it also contains a full disk image (including partition table) and
can thus be copied (using `dd`) to a USB stick; the USB stick's
content is lost in the operation.
+Then, we stopped hybrid'ing the ISO images we publish, and started
+again in Tails 1.3.
+Nowadays, we pass the `-h 255 -s 63` options to `isohybrid`, as
+advised by the syslinux community for images between 1 GiB and
+4 (?) GiB.
+What follows comes from the Tails 0.10 days.
Successful tests:
* boot the resulting `test.iso` as a normal optical drive in
diff --git a/wiki/src/contribute/design/incremental_upgrades.mdwn b/wiki/src/contribute/design/incremental_upgrades.mdwn
index 5b434e1..3ca97d5 100644
--- a/wiki/src/contribute/design/incremental_upgrades.mdwn
+++ b/wiki/src/contribute/design/incremental_upgrades.mdwn
@@ -577,6 +577,15 @@ Both with the old and new Tails upgrade systems, mounting such an
attack requires either to take control of the Tails website or to
break the SSL/TLS connection between the client and the server.
+This attack is slightly mitigated by the fact that we are announcing
+new releases in other ways:
+* one that does not rely on our website at all (Twitter);
+* one that does not rely on our website to be safe at the time Tails
+ Upgrader checks for available upgrades, as long as it was safe at
+ the time the new release was published (<>
+ announce mailing-list).
The move to a secure upgrade system, such as TUF, would make this
stronger, thanks to short-lived signatures on meta-data.
@@ -599,6 +608,10 @@ The upgrade-description files downloader and verifier could refuse to
download upgrade-description files bigger than some reasonable
constant, but this is not implemented yet.
+This attack, when performed against the upgrade-description files
+downloader and verifier is slightly mitigated in the same way as
+"Indefinite freeze attacks" are.
### Slow retrieval attacks
> An attacker responds to clients with a very slow stream of data that
diff --git a/wiki/src/contribute/design/installation.mdwn b/wiki/src/contribute/design/installation.mdwn
index cca2d6f..3fa4a51 100644
--- a/wiki/src/contribute/design/installation.mdwn
+++ b/wiki/src/contribute/design/installation.mdwn
@@ -37,7 +37,7 @@ Mode of operation and booting methods
In order to be able to have non-destructive upgrades, blind overwrites
(using `dd` or similar raw copy methods) of the boot media is not possible
-(even if Tails [[shipped hybrid ISO
+(even when Tails [[ships hybrid ISO
Two alternatives booting methods have been investigated:
diff --git a/wiki/src/contribute/design/memory_erasure.mdwn b/wiki/src/contribute/design/memory_erasure.mdwn
index 54a3e9a..6dac6f4 100644
--- a/wiki/src/contribute/design/memory_erasure.mdwn
+++ b/wiki/src/contribute/design/memory_erasure.mdwn
@@ -93,13 +93,20 @@ physically removed.
#### Making sure needed files are available
-The memlockd daemon, appropriately configured, ensures every file
+The `memlockd` daemon, appropriately configured, ensures every file
needed by the memory erasure process is locked into memory from boot
to memory erasure time.
+Care have to be taken during the shutdown sequence, as `memlockd` is normally
+unloaded before the `kexec` happens. This is done by preventing `memlockd` to
+be stopped, and also by adding memlockd PID to the list of process that are
+omitted by the `sendsigs` script (responsible for sending TERM and KILL signals
+to remaining processes).
- [[!debpts memlockd]]
- [[!tails_gitweb config/chroot_local-includes/etc/memlockd.cfg]]
- [[!tails_gitweb config/chroot_local-patches/keep_memlockd_on_shutdown.diff]]
+- [[!tails_gitweb config/chroot_local-includes/etc/init.d/tails-reconfigure-memlockd]]
#### User interface
diff --git a/wiki/src/contribute/git.mdwn b/wiki/src/contribute/git.mdwn
index a05fb2c..7b5d696 100644
--- a/wiki/src/contribute/git.mdwn
+++ b/wiki/src/contribute/git.mdwn
@@ -57,14 +57,7 @@ See our [[contribute/merge_policy]].
-If you want to commit patches that may be published later, you might
-want to anonymize them a bit; to do so, run the following commands
-in every of your local clones' directories:
- git config 'Tails developers'
- git config
-If you intend to prepare Tails releases, you'll also need to make
+If you intend to prepare Tails releases, you'll need to make
the development team signing key the default one for Git tags:
git config user.signingkey 1202821CBE2CD9C1
@@ -72,12 +65,13 @@ the development team signing key the default one for Git tags:
Creating a new repository
-1. Create a new repository at immerda.
-2. Create a pull-style mirror at
+Create a new repository at immerda.
+<a id="main-repo"></a>
Main repository
@@ -89,7 +83,7 @@ Anyone can check it out like this:
Developers with write access to the repositories should instead:
- git clone 'ssh://'
+ git clone
We have a [web interface](
available for the main repository.
@@ -167,6 +161,23 @@ any development.
Please note that the `experimental` branch can be broken, have awful
security problems and so on. No guarantee, blablabla.
+Promotion material
+This repository contains Tails [[promotion
+Anyone can check it out like this:
+ git clone
+Developers with write access to the repositories should instead:
+ git clone
+We have a [web interface](
+available for the promotion material repository.
<a id="puppet"></a>
Puppet modules
diff --git a/wiki/src/contribute/git/post-rewrite.mdwn b/wiki/src/contribute/git/post-rewrite.mdwn
new file mode 100644
index 0000000..db4e600
--- /dev/null
+++ b/wiki/src/contribute/git/post-rewrite.mdwn
@@ -0,0 +1,158 @@
+[[!meta title="What must I do now that the Git repository's history has been rewritten?"]]
+[[!toc levels=1]]
+<div class="note">
+This is about the main Tails Git repository. Other repositories, such
+as the ones for the Greeter and other custom software, are not affected.
+Back up your local Git directory
+<div class="caution">
+If you make a mistake, some of the operations below will destroy your
+great carefully hand-crafted Tails work.
+Therefore, first backup the directory where your local Git working
+directory lives.
+Store the name of the official Git remote
+Find out how you have named the Git remote that points to the official
+ OFFICIAL_REMOTE=$(git remote -v \
+ | grep --color=never -E \
+ '[a-zA-Z0-9_-]+\s+(\s+|(ssh://)?boum_org_amnesia@webmasters\.boum\.org(:wiki\.git|/~/wiki.git)).*\(fetch\)$' \
+ | awk '{print $1}')
+ [ -n "$OFFICIAL_REMOTE" ] || echo "No official remote found."
+If you see "No official remote found", then you are probably using
+a deprecated or unsafe URL for your official remote. You'll need to
+fix that first: [[find out what the correct URL
+is|contribute/git#main-repo]], and then fix it in `.git/config` and
+run the commands above again.
+<div class="caution">
+All commands that follow must be run <emph>in the same terminal</emph> as the
+previous ones: they are going to reuse the
+<code>$OFFICIAL_REMOTE</code> shell variable and may do pretty ugly
+things if it is not properly defined.
+Delete all local tags
+So that you don't publish again any deleted tag that was based on the old,
+non-rewritten history, delete all local tags you have:
+ git tag | xargs git tag -d
+Fetch the rewritten history
+Fetch the content of the updated official repository:
+ git fetch --prune "$OFFICIAL_REMOTE" && \
+ git fetch "$OFFICIAL_REMOTE" --tags
+Back up your existing local branches
+Rename every local branch so that their name starts with the
+`old-` prefix:
+ for b in $(git branch --no-color) ; do
+ [ "$b" != '*' ] || continue
+ git branch -m "$b" "old-$b"
+ done
+This is needed for two reasons:
+ * This makes sure that any work you may have started in the past, and
+ that was not merged yet, is saved somewhere and can be salvaged
+ later if needed.
+ * The `old-` prefix is meant to be a warning sign, so that you don't
+ mistakenly base future work on the old, non-rewritten Git history
+ (such work *cannot* be merged into the official repository anymore,
+ as it would re-import all the data we just managed to get rid of).
+Clean up your personal Git repository
+If you have a personal online Git repository, please consider
+following these instructions.
+It is not compulsory, but if you don't do that, then any new
+contributor who adds your personal Git repository as a Git remote will
+need to download hundreds of megabytes of useless data, which is not
+very welcoming. In particular, newcomers on your team would be
+negatively affected... and you want new teammates, right? :)
+I'm looking at you, dear translators.
+So, right now your personal Git repository contains _both_ the old
+(non-rewritten) and the new (rewritten) Git history. Here is how to
+get rid of the old one.
+### Set the `MY_REMOTE` variable
+In the following command, replace `XXX_REPLACE_ME` with the name of the remote
+that points to your personal online Git repository:
+## Delete all remote branches
+List branches that are in your personal online Git repository (in the
+following commands, ):
+ git branch --no-color -r --list "${MY_REMOTE}/*" \
+ | grep -vE "^\s+${MY_REMOTE}/HEAD\s+"
+For each such branch, check if you have work in there that can still
+be useful. If it's the case, then export it outside of Git, e.g.
+using `git format-patch`.
+Then, delete all remote branches in your personal online Git
+ for remote_branch in $(git branch --no-color -r --list "${MY_REMOTE}/*" \
+ | grep -vE "^\s+${MY_REMOTE}/HEAD\s+") ; do
+ branch=$(echo "$remote_branch" | sed -r -e "s,^${MY_REMOTE}/,,")
+ git push --force "$MY_REMOTE" ":$branch"
+ done
+## Make sure you publish only up-to-date tags
+Force-push the updated tags so that they replace the old ones in your
+personal online Git repository:
+ git push --force "$MY_REMOTE" --tags
+Start working again
+You may use `git checkout` as usual to create:
+ * a new local branch, for work you are starting right now;
+ * a new local branch tracking one that exists in the official
+ repository already, for work you are following-up on.
+Later, when you push a branch to your personal Git repository:
+* The first time you do that, it can take a while.
+* If that branch did previously exist there, then you may need to pass
+ the `--force` option to `git push`: to avoid losing data, Git
+ refuses to rewrite history on the remote by default, so in the rare
+ cases when we want to do that (which is precisely the case here),
+ one has to override this protection.
diff --git a/wiki/src/contribute/how/code.mdwn b/wiki/src/contribute/how/code.mdwn
index 55016a6..fb11d15 100644
--- a/wiki/src/contribute/how/code.mdwn
+++ b/wiki/src/contribute/how/code.mdwn
@@ -129,7 +129,7 @@ before being merged, it's better if you push your work to a dedicated
Git topic branch, and ask us to review it. If you already know where
to host your personal repository in a public online place, this is
great; otherwise, you can [fork us on](, or ask the Tails system
+GitLab](, or ask the Tails system
administrators (<>) to host your repository.
# Want more?
diff --git a/wiki/src/contribute/how/debian.mdwn b/wiki/src/contribute/how/debian.mdwn
index 74105cd..f9718df 100644
--- a/wiki/src/contribute/how/debian.mdwn
+++ b/wiki/src/contribute/how/debian.mdwn
@@ -42,8 +42,9 @@ relationship with Debian.
- [[!debpts nautilus-wipe]]
- OTR-related packages ([[!debpts pidgin-otr]], [[!debpts libotr]],
and more) in the [Debian OTR Team](
- - [[!debpts torsocks]]
- - [[!debpts vidalia]]
+ - anonymity-related packages ([[!debpts torsocks]], [[!debpts
+ vidalia]], and more) in the [Debian Anonymity Tools Team](
* Help with distribution-wide improvements:
- [AppArmor support](
- [Hardening](
diff --git a/wiki/src/contribute/how/documentation.mdwn b/wiki/src/contribute/how/documentation.mdwn
index 46e150a..db2a55e 100644
--- a/wiki/src/contribute/how/documentation.mdwn
+++ b/wiki/src/contribute/how/documentation.mdwn
@@ -23,7 +23,7 @@ translations that were made of the previous version.
But there are still many ways you can start contributing:
- We maintain a list of [documentation
- tasks](
+ tasks](
You can start writing a draft in the corresponding ticket and then
[[ask us for review|contribute/talk]].
@@ -39,9 +39,9 @@ Documentation writers coordinate themselves using our usual
Documentation writers should also read our [[documentation
-If you want to test your contributions before to sharing them with us,
-you can [[build and update the documentation
+We recommend you to [[build an offline version of the
+documentation|contribute/build/website]] to test your contributions
+before sharing them with us.
# Translating
diff --git a/wiki/src/contribute/how/documentation/guidelines.mdwn b/wiki/src/contribute/how/documentation/guidelines.mdwn
index 77a563e..ef4d02b 100644
--- a/wiki/src/contribute/how/documentation/guidelines.mdwn
+++ b/wiki/src/contribute/how/documentation/guidelines.mdwn
@@ -137,6 +137,12 @@ using <span class="application">Tails OpenPGP Applet</span>.
+Ikiwiki shortcuts
+The `\[[!wikipedia ..]]` strings you can find in some files are ikiwiki [[shortcuts]].
+You might also need to understand [[ikiwiki directives|ikiwiki/directive]].
Related online resources
diff --git a/wiki/src/contribute/how/ b/wiki/src/contribute/how/
index a5e6d1a..f2405e5 100644
--- a/wiki/src/contribute/how/
+++ b/wiki/src/contribute/how/
@@ -6,19 +6,20 @@
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
-"POT-Creation-Date: 2014-09-22 12:27+0300\n"
-"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
-"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
+"POT-Creation-Date: 2015-02-22 12:54+0100\n"
+"PO-Revision-Date: 2015-01-25 16:15-0000\n"
+"Last-Translator: Tails developers <>\n"
"Language-Team: LANGUAGE <>\n"
"Language: \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
+"X-Generator: Poedit 1.5.4\n"
#. type: Plain text
#, no-wrap
msgid "[[!meta title=\"Make a donation\"]]\n"
-msgstr ""
+msgstr "[[!meta title=\"Eine Spende tätigen\"]]\n"
#. type: Plain text
#, no-wrap
@@ -26,17 +27,21 @@ msgid ""
"**Your support is critical to our success.** Consider making\n"
"a donation to Tails.\n"
msgstr ""
+"**Ihre Hilfe ist ausschlaggebend für unseren Erfolg.** Bitte erwägen Sie,\n"
+" Tails eine Spende zukommen zu lassen.\n"
#. type: Plain text
msgid ""
"Note that Tails is a project mainly run by volunteers. There are [[many "
"other ways to contribute|contribute]]!"
msgstr ""
+"Beachten Sie, dass Tails ein hauptsächlich von Freiwilligen betriebenes "
+"Projekt ist. Es gibt [[viele andere Wege sich einzubringen|contribute]]!"
#. type: Title =
#, no-wrap
msgid "Ways to donate\n"
-msgstr ""
+msgstr "Möglichkeiten zu Spenden\n"
#. type: Bullet: ' * '
msgid ""
@@ -44,17 +49,22 @@ msgid ""
msgstr ""
+"Crowdfunding Kampagne der amerikanischen Organisation [Freedom of the Press "
#. type: Plain text
#, no-wrap
msgid " If you live in the US, your donation will be tax-deductible.\n"
-msgstr ""
+msgstr " Falls Sie in den USA leben wird Ihre Spende von der Steuer absetzbar sein.\n"
#. type: Bullet: ' * '
msgid ""
"[[Bank wire transfer|donate#swift]] or [[Paypal|donate#paypal]] through the "
"German organization [Zwiebelfreunde e.V.]("
msgstr ""
+"[[Banküberweisung|donate#swift]] oder [[Paypal|donate#paypal]] über die "
+"deutsche Organisation [Zwiebelfreunde e.V.]("
#. type: Plain text
#, no-wrap
@@ -64,10 +74,14 @@ msgid ""
" Zwiebelfreunde]( for a donation\n"
" receipt if you need one.\n"
msgstr ""
+" Wenn Sie in Europa leben, lässt sich Ihre Spende möglicherweise von der Steuer absetzen. Überprüfen Sie die genauen\n"
+" Bedingungen in Ihrem Land und [fragen Sie \n"
+" Zwiebelfreunde]( nach einer\n"
+" Spendenquittung, falls Sie eine benötigen.\n"
#. type: Bullet: ' * '
msgid "[[Bitcoin|donate#bitcoin]]"
-msgstr ""
+msgstr "[[Bitcoin|donate#bitcoin]]"
#. type: Bullet: ' * '
msgid ""
@@ -75,30 +89,33 @@ msgid ""
"( They do great work, and also support "
"us financially."
msgstr ""
+"Falls Ihnen keine dieser Methoden zusagt, können Sie auch [eine Spende an "
+"das Tor Project]( in Betracht ziehen. Sie "
+"leisten großartige Arbeit und unterstützen uns ebenfalls finanziell."
#. type: Plain text
msgid "Thank you for your donation!"
-msgstr ""
+msgstr "Vielen Dank für Ihre Spende!"
#. type: Plain text
#, no-wrap
msgid "<a id=\"bitcoin\"></a>\n"
-msgstr ""
+msgstr "<a id=\"bitcoin\"></a>\n"
#. type: Title -
#, no-wrap
msgid "Bitcoin\n"
-msgstr ""
+msgstr "Bitcoin\n"
#. type: Plain text
#, no-wrap
msgid "You can send Bitcoins to **<a href=\"bitcoin:1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2\">1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2</a>**.\n"
-msgstr ""
+msgstr "Sie können Bitcoins an **<a href=\"bitcoin:1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2\">1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2</a>** senden.\n"
#. type: Plain text
#, no-wrap
msgid "<div class=\"caution\">\n"
-msgstr ""
+msgstr "<div class=\"caution\">\n"
#. type: Plain text
#, no-wrap
@@ -106,21 +123,23 @@ msgid ""
"<p>Bitcoin is <a href=\"\">not\n"
msgstr ""
+"<p>Bitcoin ist <a href=\"\">nicht\n"
#. type: Plain text
#, no-wrap
msgid "</div>\n"
-msgstr ""
+msgstr "</div>\n"
#. type: Plain text
#, no-wrap
msgid "<a id=\"swift\"></a>\n"
-msgstr ""
+msgstr "<a id=\"swift\"></a>\n"
#. type: Title -
#, no-wrap
msgid "Bank wire transfer\n"
-msgstr ""
+msgstr "Banküberweisung\n"
#. type: Plain text
#, no-wrap
@@ -131,27 +150,34 @@ msgid ""
" Address of bank: Christstrasse 9, 44789 Bochum, Germany\n"
msgstr ""
+" Kontoinhaber: Zwiebelfreunde e.V.\n"
+" Name der Bank: GLS Gemeinschaftsbank eG\n"
+" IBAN: DE25430609671126825603\n"
+" Adresse der Bank: Christstrasse 9, 44789 Bochum, Deutschland\n"
#. type: Plain text
#, no-wrap
msgid "<a id=\"paypal\"></a>\n"
-msgstr ""
+msgstr "<a id=\"paypal\"></a>\n"
#. type: Title -
#, no-wrap
msgid "Paypal\n"
-msgstr ""
+msgstr "Paypal\n"
#. type: Plain text
msgid ""
"Please, use the euro (EUR) as currency as this makes accounting easier. "
"However, Paypal automatically converts it to your local currency."
msgstr ""
+"Bitte benutzen Sie Euro (EUR) als Währung, da dies die Buchhaltung "
+"vereinfacht. Paypal wird die Umrechnung in Ihre lokale Währung übernehmen."
#. type: Title ###
#, no-wrap
msgid "Set up a recurring donation"
-msgstr ""
+msgstr "Eine Spende per Dauerauftrag einrichten"
#. type: Plain text
#, no-wrap
@@ -205,11 +231,59 @@ msgid ""
"\t<input type=\"submit\" value=\"Subscribe\" class=\"button\" />\n"
msgstr ""
+"<form action=\"\" method=\"post\" target='_blank' class='donation'>\n"
+"\t<input type=\"hidden\" name=\"cmd\" value=\"_xclick-subscriptions\"/>\n"
+"\t<input type=\"hidden\" name=\"business\" value=\"\"/>\n"
+"\t<input type=\"hidden\" name=\"item_name\" value=\"Tails recurring donation\"/>\n"
+"\t<input type=\"hidden\" name=\"no_note\" value=\"1\"/>\n"
+"\t<input type=\"hidden\" name=\"src\" value=\"1\"/>\n"
+"\t<input type=\"hidden\" name=\"modify\" value=\"1\"/>\n"
+"\t<input type=\"hidden\" name=\"t3\" value=\"M\"/>\n"
+"\t<input name=\"lc\" type=\"hidden\" value=\"US\" />\n"
+"\t<input type=\"radio\" name=\"a3\" value=\"5\" id=\"sub5\" checked=\"checked\" /><label for=\"sub5\">5</label>\n"
+"\t<input type=\"radio\" name=\"a3\" value=\"10\" id=\"sub10\"/><label for=\"sub10\">10</label>\n"
+"\t<input type=\"radio\" name=\"a3\" value=\"20\" id=\"sub20\"/><label for=\"sub20\">20</label>\n"
+"\t<input type=\"radio\" name=\"a3\" value=\"50\" id=\"sub50\"/><label for=\"sub50\">50</label>\n"
+"\t<input type=\"radio\" name=\"a3\" value=\"100\" id=\"sub100\"/><label for=\"sub100\">100</label>\n"
+"\t<input type=\"radio\" name=\"a3\" value=\"250\" id=\"sub250\"/><label for=\"sub250\">250</label>\n"
+"\t<input type=\"radio\" name=\"a3\" value=\"500\" id=\"sub500\"/><label for=\"sub500\">500</label>\n"
+"\t<select name=\"currency_code\">\n"
+"\t\t\t<option value='EUR'>EUR</option>\n"
+"\t\t\t<option value='USD'>USD</option>\n"
+"\t\t\t<option value='GBP'>GBP</option>\n"
+"\t\t\t<option value='CAD'>CAD</option>\n"
+"\t\t\t<option value='AUD'>AUD</option>\n"
+"\t\t\t<option value='NZD'>NZD</option>\n"
+"\t\t\t<option value='SEK'>SEK</option>\n"
+"\t\t\t<option value='CZK'>CZK</option>\n"
+"\t\t\t<option value='PLN'>PLN</option>\n"
+"\t\t\t<option value='DKK'>DKK</option>\n"
+"\t\t\t<option value='NOK'>NOK</option>\n"
+"\t\t\t<option value='MXN'>MXN</option>\n"
+"\t\t\t<option value='CHF'>CHF</option>\n"
+"\t\t\t<option value='HKD'>HKD</option>\n"
+"\t\t\t<option value='HUF'>HUF</option>\n"
+"\t\t\t<option value='ILS'>ILS</option>\n"
+"\t\t\t<option value='BRL'>BRL</option>\n"
+"\t\t\t<option value='JPY'>JPY</option>\n"
+"\t\t\t<option value='MYR'>MYR</option>\n"
+"\t\t\t<option value='PHP'>PHP</option>\n"
+"\t\t\t<option value='SGD'>SGD</option>\n"
+"\t\t\t<option value='TWD'>TWD</option>\n"
+"\t\t\t<option value='THB'>THB</option>\n"
+"\t<input type=\"radio\" name=\"p3\" value=\"1\" id=\"sub_m\" checked=\"checked\" /><label for=\"sub_m\">monatlich</label>\n"
+"\t<input type=\"radio\" name=\"p3\" value=\"3\" id=\"sub_q\"/><label for=\"sub_q\">quartalsweise</label>\n"
+"\t<input type=\"radio\" name=\"p3\" value=\"12\" id=\"sub_y\"/><label for=\"sub_y\">jährlich</label>\n"
+"\t<input type=\"submit\" value=\"Absenden\" class=\"button\" />\n"
#. type: Title ###
#, no-wrap
msgid "Make a one-time donation"
-msgstr ""
+msgstr "Eine einmalige Spende tätigen"
#. type: Plain text
#, no-wrap
@@ -255,13 +329,55 @@ msgid ""
"\t<input type=\"submit\" value=\"Donate\" class=\"button\" />\n"
msgstr ""
+"<form action='' id='paypalForm' method='post' target='_blank' class='donation'>\n"
+"\t<input name='cmd' type='hidden' value='_donations' />\n"
+"\t<input name='business' type='hidden' value='' />\n"
+"\t<input name='item_name' type='hidden' value='Tails one-time donation' />\n"
+"\t<input type=\"hidden\" name=\"no_shipping\" value=\"1\"/>\n"
+"\t<input name=\"lc\" type=\"hidden\" value=\"US\" />\n"
+"\t<input type=\"radio\" name=\"amount\" value=\"5\" id=\"pp_5\" /><label for=\"pp_5\">5</label>\n"
+"\t<input type=\"radio\" name=\"amount\" value=\"10\" id=\"pp_10\"/><label for=\"pp_10\">10</label>\n"
+"\t<input type=\"radio\" name=\"amount\" value=\"20\" id=\"pp_20\"/><label for=\"pp_20\">20</label>\n"
+"\t<input type=\"radio\" name=\"amount\" value=\"50\" id=\"pp_50\"/><label for=\"pp_50\">50</label>\n"
+"\t<input type=\"radio\" name=\"amount\" value=\"100\" id=\"pp_100\"/><label for=\"pp_100\">100</label>\n"
+"\t<input type=\"radio\" name=\"amount\" value=\"\" id=\"pp_cust\" checked=\"checked\"/><label for=\"pp_cust\">anderer Betrag</label>\n"
+"\t<select name=\"currency_code\">\n"
+"\t\t<option value='EUR'>EUR</option>\n"
+"\t\t<option value='USD'>USD</option>\n"
+"\t\t<option value='GBP'>GBP</option>\n"
+"\t\t<option value='CAD'>CAD</option>\n"
+"\t\t<option value='AUD'>AUD</option>\n"
+"\t\t<option value='NZD'>NZD</option>\n"
+"\t\t<option value='SEK'>SEK</option>\n"
+"\t\t<option value='CZK'>CZK</option>\n"
+"\t\t<option value='PLN'>PLN</option>\n"
+"\t\t<option value='DKK'>DKK</option>\n"
+"\t\t<option value='NOK'>NOK</option>\n"
+"\t\t<option value='MXN'>MXN</option>\n"
+"\t\t<option value='CHF'>CHF</option>\n"
+"\t\t<option value='HKD'>HKD</option>\n"
+"\t\t<option value='HUF'>HUF</option>\n"
+"\t\t<option value='ILS'>ILS</option>\n"
+"\t\t<option value='BRL'>BRL</option>\n"
+"\t\t<option value='JPY'>JPY</option>\n"
+"\t\t<option value='MYR'>MYR</option>\n"
+"\t\t<option value='PHP'>PHP</option>\n"
+"\t\t<option value='SGD'>SGD</option>\n"
+"\t\t<option value='TWD'>TWD</option>\n"
+"\t\t<option value='THB'>THB</option>\n"
+"\t<input type=\"submit\" value=\"Spenden\" class=\"button\" />\n"
#. type: Title =
#, no-wrap
msgid "How does Tails use this money?\n"
-msgstr ""
+msgstr "Wofür verwendet Tails dieses Geld?\n"
#. type: Plain text
msgid ""
"Our [[financial documents|doc/about/finances]] are available for your review."
msgstr ""
+"Unsere [[Auflistungen über die Verwendung der Zuwendungen|doc/about/"
+"finances]] sind für Sie einsehbar."
diff --git a/wiki/src/contribute/how/mirror.mdwn b/wiki/src/contribute/how/mirror.mdwn
index 26746df..474a6b5 100644
--- a/wiki/src/contribute/how/mirror.mdwn
+++ b/wiki/src/contribute/how/mirror.mdwn
@@ -139,7 +139,16 @@ enabled.
Download a snapshot of the current Tails files:
- rsync -rt --delete \
+ rsync -rt --delete \
+ \
+If you have disk space limitations, you might want to exclude the
+`/tails/obsolete` folder (which contains old versions of Tails) from the
+ rsync -rt --delete --exclude=/tails/obsolete --delete-excluded \
+ \
4. Schedule the pulling of the files
diff --git a/wiki/src/contribute/how/promote.mdwn b/wiki/src/contribute/how/promote.mdwn
index 36be952..0172c1a 100644
--- a/wiki/src/contribute/how/promote.mdwn
+++ b/wiki/src/contribute/how/promote.mdwn
@@ -36,11 +36,12 @@ on Redmine.
# Advertising material
-Some minimal amount of advertising material is available already:
+Some minimal amount of [[advertising material|promote/material]] is available already:
* [[Press and media information|press]]
- * [[DVD label|promote/cd_label.pdf.gz]]
- * [[Slides|promote/slides]]
+ * [[DVD label|promote/material/cd_label.pdf.gz]]
+ * [[Slides|promote/material/slides]]
+ * [[Stickers|promote/material/stickers]]
As you can see, there is room for improvement. Do not hesitate adding
to the list!
diff --git a/wiki/src/contribute/how/promote/material.mdwn b/wiki/src/contribute/how/promote/material.mdwn
new file mode 100644
index 0000000..f6171a5
--- /dev/null
+++ b/wiki/src/contribute/how/promote/material.mdwn
@@ -0,0 +1,6 @@
+[[!meta title="Advertising material"]]
+Here, we list material that can be used to promote Tails.
+[[Read more|contribute/how/promote]] about promoting Tails.
+[[!map pages="contribute/how/promote/material/*"]]
diff --git a/wiki/src/contribute/how/translate/team/de.mdwn b/wiki/src/contribute/how/translate/team/de.mdwn
index 61f7e68..94da28c 100644
--- a/wiki/src/contribute/how/translate/team/de.mdwn
+++ b/wiki/src/contribute/how/translate/team/de.mdwn
@@ -1,5 +1,17 @@
[[!meta title="Translate Tails into German"]]
+[[!toc levels=2]]
+# What can be translated
+* **This website** must be translated in the `master` branch of the
+ [main Tails Git repository](
+ Please read the documentation about [[translating with
+ Git|translate/with_Git]] first.
+* The German team does not use Git to **translate Tails custom programs**.
+ Instead, and for this part only, we rely on [[Transifex|translate/with_Transifex]].
# Glossaries used by the German translation team
We try to follow the [GNOME Guidelines](
@@ -8,5 +20,29 @@ and their glossaries:
* <>
* <>
+As well as the Transifex glossary of the Torproject (you need to be logged in with
+Transifex to see this page):
+* <>
For words not in these lists it is helpful to see
how they are translated (or not translated) in Wikipedia.
+Often, we simply discuss on the [[mailing list for
+translators|]] if
+unsure which term applies best.
+# Contributors' repositories
+In alphabetical order:
+* flapflap: [[]]<br/>
+ OpenPGP: `2354 8DDD 83F5 3E54 024C E4CC 73F0 75CE 217E 3C9F`
+* muri: [[]]<br/>
+ OpenPGP: `0A22 2156 C805 923B B6A5 C26A 076D 7386 D16D 072E`
+* spriver: [[]]<br/>
+ OpenPGP: `179E 23A5 4D25 CF05 FC5F A67A C914 7FC5 687A 380F`
+* sycamoreone: [[]]<br/>
+ OpenPGP: `7204 C800 522E 14C0 7F87 1C6D E6AE 11A3 F6B8 D449`
+* u: [[]]<br/>
+ OpenPGP: `EDE3 F444 3F34 D261 9514 D790 B14B B0C3 8D86 1CF1`
diff --git a/wiki/src/contribute/how/translate/with_Git.mdwn b/wiki/src/contribute/how/translate/with_Git.mdwn
index 15bd8fd..bc7436e 100644
--- a/wiki/src/contribute/how/translate/with_Git.mdwn
+++ b/wiki/src/contribute/how/translate/with_Git.mdwn
@@ -71,7 +71,7 @@ ask on the [[mailing list for translators|translate#follow-up]], we will be glad
Git server. There are a lot of websites providing you with such a possibility.
If you already know where to host it in a public place, this is great;
- else, [fork us on]( or ask
+ else, [fork us on GitLab]( or ask
the Tails system administrators (<>) to host
your repository.
@@ -82,7 +82,7 @@ ask on the [[mailing list for translators|translate#follow-up]], we will be glad
This example clones an empty repository into the "tails" folder:
- git clone tails
+ git clone tails
2. **Copy the source code from the main repository**
@@ -98,8 +98,8 @@ ask on the [[mailing list for translators|translate#follow-up]], we will be glad
More specifically, if you type `git remote -v` and you'll see something like this:
- origin ssh:// (fetch)
- origin ssh:// (push)
+ origin (fetch)
+ origin (push)
tails (fetch)
tails (push)
@@ -176,7 +176,7 @@ ask on the [[mailing list for translators|translate#follow-up]], we will be glad
Each [[language team|translate#language-teams]] keeps track of their contributors' repositories.
To add one of these repositories as a `remote` in Git, use the following command line:
- git remote add [name] git://[name].git
+ git remote add [name][name].git
For example:
diff --git a/wiki/src/contribute/l10n_tricks.mdwn b/wiki/src/contribute/l10n_tricks.mdwn
index 462adbb..2f8a265 100644
--- a/wiki/src/contribute/l10n_tricks.mdwn
+++ b/wiki/src/contribute/l10n_tricks.mdwn
@@ -40,20 +40,22 @@ up/down, you can add those lines in .vimrc:
Check the validity of PO files
-Use the tool [i18nspector](
-To copy, install and run it issue the following commands in the folder where
-you want to download it:
+To check the validity of PO files, install [i18nspector](
+by running the following command line, as root:
apt-get install i18nspector/unstable
+You can then check a single file:
i18nspector <PO file>
-Run i18nspector on the whole wiki
+or the whole wiki:
cd wiki/src
+You can get an explaination of each error message on the [[following documentation|]]
Rewrap files
@@ -114,3 +116,8 @@ Execute from the root of the Git repository:
+Get an overview of translation progress
+You can get a list of pages that are not 100% translated on [[this dedicated page|contribute/how/translate/translation_progress]].
diff --git a/wiki/src/contribute/l10n_tricks/ b/wiki/src/contribute/l10n_tricks/
index 24af675..f781c52 100755
--- a/wiki/src/contribute/l10n_tricks/
+++ b/wiki/src/contribute/l10n_tricks/
@@ -37,6 +37,7 @@ no-package-name-in-project-id-version
" | grep -v '^$' > "$PATTERNS_FILE"
diff --git a/wiki/src/contribute/meetings.mdwn b/wiki/src/contribute/meetings.mdwn
index d922083..fc29642 100644
--- a/wiki/src/contribute/meetings.mdwn
+++ b/wiki/src/contribute/meetings.mdwn
@@ -25,6 +25,15 @@ introduce newcomers to the development process
at least it should be a fine place to know each others, and schedule
a better suited event.
+# Instructions for taking notes
+ - Explain in details the decisions that were taken.
+ - Keep track of the brainstorming that we did if no decision was
+ taken.
+ - Include names of people who took responsibilities.
+ - Update Redmine tickets accordingly and point them to the meeting
+ notes (unless someone else volunteers to do it on some tickets).
# Meeting minutes
[[!map pages="contribute/meetings/*"]]
diff --git a/wiki/src/contribute/meetings/201501.mdwn b/wiki/src/contribute/meetings/201501.mdwn
new file mode 100644
index 0000000..f1cd79d
--- /dev/null
+++ b/wiki/src/contribute/meetings/201501.mdwn
@@ -0,0 +1,44 @@
+[[!meta title="January 2015 meeting"]]
+[[!toc levels=1]]
+# [[!tails_ticket 7779 desc="Revisit default touchpad settings"]]
+ - During the meeting we agreed that reasonable defaults would be:
+ - tap-to-click
+ - 2-fingers scroll
+ - disable while typing
+ - no reverse scrolling
+# [[!tails_ticket 8423 desc="Document that Pidgin can't open an account with Persistence enabled in Read-only mode"]]
+ - We confirmed that the read-only option for persistence is a
+ best-effort feature. So documenting the bug looks good enough for
+ now.
+ - Real fix and automated tests for the read-only mode are more than
+ welcome.
+# [[!tails_ticket 8237 desc="Greeter revamp: Decide a language icon"]]
+ - We acknowledged the current design.
+ - The Japanese character has been reversed and this needs to be fixed.
+ This will be part of [[!tails_ticket 8523]].
+# [[!tails_ticket 8447 desc="Persistent data is not erased when persistence features are disabled"]]
+ - We acknowledged the proposal from [comment 4](
+ - We can't really say "securely delete" on flash media. So that needs rephrasing.
+# [[!tails_ticket 8443 desc="Adding a new printer requires administration password"]]
+ - We acknowledged the proposal from [comment 9](
+ - DrWhax will try to do it for 1.3.
+# [[!tails_ticket 8510 desc="Reconsider distributing a hybrid ISO image"]]
+ 1. We will [[!tails_ticket 8524 desc="do statistics on whether bug reports come from a DVD or flash media"]].
+ 2. We will [[!tails_ticket 8525 desc="test isohybrid DVD on Macs"]].
+ 3. If our experiments are successful, then we will release an
+ isohybrid image, update the documentation, and see what happens.
+ 4. Then if users and frontdesk hate us, revisit. Otherwise, forget it
+ and keep isohybrid images.
diff --git a/wiki/src/contribute/meetings/201502.mdwn b/wiki/src/contribute/meetings/201502.mdwn
new file mode 100644
index 0000000..d2f6cb8
--- /dev/null
+++ b/wiki/src/contribute/meetings/201502.mdwn
@@ -0,0 +1,33 @@
+[[!meta title="February 2015 meeting"]]
+[[!toc levels=1]]
+# [[!tails_ticket 8244 desc="Greeter revamp: Decide if we want to keep the wording 'Quick setup'"]]
+Postpone: the ticket was not relevant to discuss according to the latest
+discussions and mockups.
+# [[!tails_ticket 6432 desc="WhisperBack launcher in the applications menu should give a hint about its function"]]
+We choose to go with the "WhisperBack Error Reporting" wording.
+# [[!tails_ticket 7076 desc="Warn against plugging a Tails device in untrusted systems"]]
+We choose to put the warn in the "Warnings" page, and see later if this page
+grows too big.
+# [[!tails_ticket 8253 desc="Ship a tool to quickly edit (resize...) pictures"]]
+This could fit in the use cases, so we need a GUI tool for that. There are a
+bunch of nautilus plugins that can do that, so next step is to test them and
+pick one or none. Requirements: sanely developed and maintained upstream.
+# [[!tails_ticket 8796 desc="Consider using the purple of the logo as background color"]]
+We decided to ship a darker blue blackground. Someone building a proposal or
+willing to lead a discussion about visual identity would be welcome.
+# [[!tails_ticket 8696 desc="Consider hiding the TBB logo in Tor Launcher "]]
+We will remove this logo, so ticket about using that envvar for that.
diff --git a/wiki/src/contribute/merge_policy/review.mdwn b/wiki/src/contribute/merge_policy/review.mdwn
index 6d81404..ce4e441 100644
--- a/wiki/src/contribute/merge_policy/review.mdwn
+++ b/wiki/src/contribute/merge_policy/review.mdwn
@@ -22,7 +22,7 @@
## Merge
-On the Git side, merge the branch with `--no-ff` :
+On the Git side, merge the branch with `--no-ff`:
- for a new feature: into `devel`; then merge `devel` into
@@ -31,6 +31,16 @@ On the Git side, merge the branch with `--no-ff` :
- for a fix on top of the last stable: into `stable`; then merge
`stable` into `devel`, and `devel` into `experimental`
+<a id="fix-committed"></a>
+Please consider including `fix-committed: #NNNN` in the commit
+message, _NNNN_ being the ticket number that is fixed by the branch
+you are merging. Then, Redmine will automatically flag the
+corresponding ticket as "Fix committed" once you push the results of
+your merge to our main [[Git repository|contribute/Git]]. For example:
+ Merge branch 'bugfix/8470-clean-up-apt-pinning' (Fix-committed: #8470)
On the APT repository side,
[[merge the suites|APT_repository#workflow-merge-topic-branch]].
@@ -38,7 +48,8 @@ On the APT repository side,
1. Update the *QA Check* field on the ticket. If there is no remaining
tasks listed on the ticket, then change its status to *Fix
- committed*; else, ask the branch submitter to split the remaining tasks
+ committed* (unless you used the `fix-committed` keyword documented
+ above); else, ask the branch submitter to split the remaining tasks
into other tickets.
1. Push the updated branch to the master Git repository.
1. Reply to the email that requested the review.
diff --git a/wiki/src/contribute/merge_policy/submit.mdwn b/wiki/src/contribute/merge_policy/submit.mdwn
index 3348365..71186d6 100644
--- a/wiki/src/contribute/merge_policy/submit.mdwn
+++ b/wiki/src/contribute/merge_policy/submit.mdwn
@@ -8,6 +8,7 @@ branch name, e.g. `bugfix/7173-upgrade-syslinux`.
When the developer thinks it is good enough and has tested it, she must:
- if you have the commit bit, merge the topic branch into the `experimental` one
+- set the ticket's *Status* field to *In Progress*
- set the ticket's *QA Check* field to *Ready for QA*
- assign this ticket to nobody (aka. unassign it from yourself) by
default. Unless it's clear to you that the current release manager won't be able
@@ -17,11 +18,12 @@ When the developer thinks it is good enough and has tested it, she must:
- set the ticket's *Feature Branch* field
- set the ticket's *Target version* field to the release you would
like your changes to be in
-- ask for a review and merge (in devel generally, in testing
+- ask for a review and merge (into devel generally, into testing
or stable for bugfixes) by writing to the ``
-Then, if the reviewer asks for more development to be done before
+Then, if the [[reviewer|contribute/merge_policy/review]] asks for more
+development to be done before
merging, they should set the ticket's *QA Check* field back to *Needs
more dev* or *Needs more info* state, and
from now on it's the responsibility of the branch/ticket "holder" to
diff --git a/wiki/src/contribute/release_process.mdwn b/wiki/src/contribute/release_process.mdwn
index eb532e65..0d53de0 100644
--- a/wiki/src/contribute/release_process.mdwn
+++ b/wiki/src/contribute/release_process.mdwn
@@ -241,21 +241,16 @@ points translators to up-to-date PO files:
Call for translation
-If at freeze time:
+If at freeze time, send a call for translations to tails-l10n, making it clear what
+Git branch the translations must be based on, and what are the
+priorities. Also, add a few words to remember the translation teams
+using Git that they should regularly contact Transifex translators,
+as detailed on the [[documentation for
-1. Ask on tails-l10n that someone checks the PO files of `po/` and of
- the website [[using ``|contribute/l10n_tricks]], and
- corrects all the errors.
-2. Send a call for translations to tails-l10n, making it clear what
- Git branch the translations must be based on, and what are the
- priorities. Also, add a few words to remember the translation teams
- using Git that they should regularly contact Transifex translators,
- as detailed on the [[documentation for
- translators|contribute/how/translate]].
+To get a list of changes on the website:
- To get a list of changes on the website:
- git diff --stat 1.1.. -- *.{mdwn,html}
+ git diff --stat 1.1.. -- *.{mdwn,html}
Import the signing key
@@ -295,6 +290,20 @@ repository documentation.
Build images
+Sanity check
+Verify that the TBB release used in Tails still is the most
+recent. Also look if there's a new `-buildX` tag for the targetted TBB
+and Tor Browser versions in their respective Git repos:
+* <>
+* <>
+A new tag may indicate that a new TBB release is imminent.
+Better catch this before people spend time doing manual tests.
Build the almost-final image
@@ -504,16 +513,8 @@ Upload images
Sanity check
-Verify that the TBB release used in Tails still is the most
-recent. Also look if there's a new `-buildX` tag for the targetted TBB
-and Tor Browser versions in their respective Git repos:
-* <>
-* <>
-A new tag may indicate that a new TBB release is imminent.
-Better catch this before people spend time doing manual tests.
+Verify once more that the TBB we ship is still the most recent (see
## Announce, seed and test the Torrents
@@ -792,6 +793,15 @@ Tor weekly news
Write a short announcement for the Tor weekly news, or find someone
who's happy to do it.
+Amnesia news
+The release notes should have been automatically sent to
+`amensia-news@` (thanks to the `announce` flag) but it will be stuck
+in the moderation
+queue. [Log in]( and
+accept it.
Prepare for the next release
@@ -801,6 +811,26 @@ this, and skip what does not make sense for a RC.
1. Move the previous stable release to `obsolete` on the mirrors.
1. Remove any remaining RC for the just-published release from
the mirrors.
+1. Remove IUKs that are more than 6 months old from
+ `/{stable,alpha}/iuk` on the rsync server:
+ - first check that it's not going to remove anything we want to keep:
+ ssh rsync.lizard /bin/sh -c \
+ \"find /srv/rsync/tails/tails/alpha \
+ /srv/rsync/tails/tails/stable \
+ -type f -name '*.iuk' -mtime '+183' \
+ -ls \
+ \"
+ - then actually delete the files:
+ ssh rsync.lizard /bin/sh -c \
+ \"find /srv/rsync/tails/tails/alpha \
+ /srv/rsync/tails/tails/stable \
+ -type f -name '*.iuk' -mtime '+183' \
+ -delete \
+ \"
1. Pull `master` back and merge it into `devel`.
1. Follow the
[[post-release|contribute/APT_repository#workflow-post-release]] APT
diff --git a/wiki/src/contribute/release_process/liveusb-creator/topic_branch.mdwn b/wiki/src/contribute/release_process/liveusb-creator/topic_branch.mdwn
index 48b01bf..4a14ed2 100644
--- a/wiki/src/contribute/release_process/liveusb-creator/topic_branch.mdwn
+++ b/wiki/src/contribute/release_process/liveusb-creator/topic_branch.mdwn
@@ -5,11 +5,15 @@ follows:
1. `git checkout -b debian_$TOPIC debian`
2. `git merge feature/$TOPIC`
-3. Use `git-dch --auto --snapshot` too fill `debian/changelog`, and
- insert something like "+feature.$TOPIC" (with all special
+3. Use `git-dch --auto --snapshot --ignore-branch` too fill `debian/changelog`, and
+ insert something like "+feature.$TOPIC.1bugfix-6092-drop-racy-code" (with all special
characters changed to full stops, i.e. ".") between the version
last packaged in the "debian" branch, and the gbp snapshot number
(that looks like "~1.gbpNNNNNN"). In the end, if `$TOPIC =
7000-blah-bleh` it should look something like:
-4. Then build with `git-buildpackage --git-ignore-branch`.
+4. Commit the changelog:
+ git commit debian/changelog
+5. Build with `git-buildpackage --git-ignore-branch`.
diff --git a/wiki/src/contribute/release_process/test.mdwn b/wiki/src/contribute/release_process/test.mdwn
index 9f3c93d..85bd772 100644
--- a/wiki/src/contribute/release_process/test.mdwn
+++ b/wiki/src/contribute/release_process/test.mdwn
@@ -118,11 +118,11 @@ tracked by tickets prefixed with `todo/test_suite:`.
* Check that Pidgin doesn't leak too much information when replying to
CTCP requests:
* Start Tails, launch Pidgin, and join #tails.
- * Also join #tails from the webchat of OFTC on <>
- using another nickname.
- * Try to send `/ctcp <Tails_account_nick> COMMAND` from the webchat to pidgin:
- - You should get no answer apart for the commands listed in [[!tails_ticket
- 5823]].
+ * Also join #tails from a client that supports CTCP commands
+ properly, e.g. Konversation.
+ * Try to send `/ctcp <Tails_account_nick> COMMAND` from the other client to Pidgin:
+ - You should get no answer apart for the PING and VERSION commands
+ ([[!tails_ticket 5823]]).
- List of `/ctcp` commands, see [this page](
@@ -133,209 +133,15 @@ tracked by tickets prefixed with `todo/test_suite:`.
# Tor
-(automate: [[!tails_ticket 7821]])
* The version of Tor should be the latest stable one, which is the highest version number
before alpha releases on <>.
-* Check that the firewall-level Tor enforcement is effective:
- - check output of `iptables -L -n -v`
- - check output of `iptables -t nat -L -n -v`
- - try connecting to the Internet after unsetting `$http_proxy` and
- `$HTTP_PROXY` using a piece of software that does not obey the
- GNOME proxy settings, *and* is not explicitly torified in Tails:
- unset http_proxy ; unset HTTP_PROXY
- wget --no-proxy
- ... should only give you "Connection refused" error message.
-* Check that IPv6 traffic is blocked:
- - check output of `ip6tables -L -n`
- - at a place with working IPv6: try connecting to a known-working
- IPv6-enabled server on its IPv6 address over TCP and icmp6.
-* After DHCP has been set up, `/etc/resolv.conf` must read `nameserver`.
-* Before DHCP has been set up, `/etc/resolv.conf` must read `nameserver`.
-* [[doc/first_steps/startup_options/bridge_mode]] should work:
- 1. Set up an administrator password.
- 1. Enable network configuration in Tails Greeter.
- 1. Configure a few bridges in Tor Launcher:
- bridge
- obfs2
- obfs3
- 1. Use the Internet.
- 1. Check that the only outgoing direct network connections go to the
- configured bridges:
- sudo watch "netstat -taupen | grep ESTABLISHED"
-* Verify that all destinations reached from an intensive Tails session
- are tor routers or
- authorities:
- 1. Boot Tails without the network in.
- 1. Set up an administration password.
- 1. Start dumping your whole session's network activity with `sudo
- tcpdump -n -i any -w dump` (or better, do the dump on another machine,
- or on the host OS if Tails is running in a VM).
- 1. Plug the network.
- 1. Wait for Tor to be functional.
- 1. Save `/var/lib/tor/cached-microdesc-consensus` out of the VM (it's needed
- to analyze the network dump later on).
- 1. Do *a lot* of network stuff (why not run do this while doing all
- the other tests **but** I2P and the unsafe browser, which would
- show many false positives?)
- 1. Then check all destinations, e.g. by using tshark and the script below:
- # set DUMP to the output of tcpdump above
- DUMP=dump
- # set CONSENSUS to Tor's consensus from the Tails session
- CONSENSUS=cached-microdesc-consensus
- NODES=$(mktemp)
- awk '/^r / { print $6 }' ${CONSENSUS} > ${NODES}
- # Note that these default directory authorities may change! To be
- # sure, check in Tor's source, src/or/config.c:~900
- "
- tshark -r ${DUMP} -T fields -e ip.dst | sort | uniq | \
- while read x; do
- ip_expr=$(echo ${x} | sed -e "s@\.@\\\.@g")
- if echo ${DIR_AUTHS} | grep -qe "${ip_expr}"; then
- continue
- fi
- if ! grep -qe "^${ip_expr}$" ${NODES}; then
- echo "${x} is bad"
- fi
- done
- rm ${NODES}
- Note that this script will produce some false positives, like your
- gateway, broadcasts, etc.
-## Stream isolation
-See our [[stream isolation design
-page|contribute/design/stream_isolation]] for details such as port
-numbers, that are not duplicated here to avoid desynchronization.
-Assumptions for the following tests: first, Tor stream isolation
-features properly do their work; second, our `torrc` sets the right
-`SocksPort` options to implement what we want.
-**Note**: the following commands would advantageously be replaced with
-the appropriate tcpdump or tshark filters.
-* Make sure Claws Mail use its dedicated `SocksPort` when connecting
- to IMAP / POP3 / SMTP servers:
- sudo watch -n 0.1 'netstat -taupen | grep claws'
-* Make sure these use the `SocksPort` dedicated for Tails-specific applications:
- - htpdate — as root, run:
- service htpdate stop \
- && rm -f /var/run/htpdate/{done,success} \
- && service htpdate start
- ... with the following command running in another terminal:
- sudo watch -n 0.1 'netstat -taupen | grep curl'
- - security check — run `tails-security-check` with the following
- command running in another terminal:
- sudo watch -n 0.1 'netstat -taupen | grep perl'
- - incremental upgrades — run `tails-upgrade-frontend-wrapper` with
- the following command running in another terminal:
- sudo watch -n 0.1 'netstat -taupen | grep perl'
-* Make sure the Tor Browser uses its dedicated `SocksPort`: quit the Tor Browser
- then start it with the following command running in another
- terminal:
- sudo watch -n 0.1 'netstat -taupen | grep firefox'
-* Make sure other applications use the default system-wide
- `SocksPort`:
- - Polipo — run:
- wget
- ... with the following command running in another terminal:
- sudo watch -n 0.1 'netstat -taupen | grep polipo'
- - Gobby 0.5 — start Gobby 0.5 from the *Applications* menu and
- connect to a server (for example ``), with the following command running in
- another terminal:
- sudo watch -n 0.1 'netstat -taupen | grep gobby'
- - SSH — run (no need to authenticate the server or to login):
- ssh
- ... with the following command running in another terminal:
- sudo watch -n 0.1 'netstat -taupen | grep -E "connect-proxy|ssh"'
- - whois — run:
- whois
- ... with the following command running in another terminal:
- sudo watch -n 0.1 'netstat -taupen | grep whois'
-* Make sure a random application run using `torify` and `torsocks`
- uses the default system-wide `SocksPort`. Run:
- torify /usr/bin/gobby-0.5
- ... and connect to a server (for example ``), with the following command running
- in another terminal:
- sudo watch -n 0.1 'netstat -taupen | grep gobby'
- Then do the same test for:
- torsocks /usr/bin/gobby-0.5
-# Use of untrusted partitions
-(automate: [[!tails_ticket 7822]])
-* Is any local hard-disk swap partition used as swap?
- boot on a (possibly virtual) machine that has a cleartext swap
- partition not managed by LVM. To verify that a local GTP partition is swap,
- check its type code with `sgdisk -p`, Linux swap is code 8200.
- This swap partition must not be used by Tails. Run `cat /proc/swaps`.
-* Is a persistence volume on a local hard-disk partition used?
- (Hint: setup a libvirt USB disk with GPT and a partition labeled
- `TailsData`, set the `removable` flag on it, check that
- tails-greeter proposes to enable persistence. Then remove the
- `removable` flag, and check that tails-greeter does not propose to
- enable persistence anymore.)
# Claws
* Check mail over IMAP using:
- a "clearnet" IMAP server.
- - a hidden service IMAP server (e.g. TorMail, jhiwjjlqpyawmpjx.onion, or
- Riseup, zsolxunfmbfuq7wf.onion with SSL).
+ - a hidden service IMAP server (e.g. Riseup, zsolxunfmbfuq7wf.onion
+ with SSL).
* Send an email using:
- a "clearnet" SMTP server.
- a hidden service SMTP server (see above).
@@ -357,6 +163,11 @@ the appropriate tcpdump or tshark filters.
verify that it only contains `localhost`: `tcpdump -A -r dump`
5. Check the `Received:` and `Message-Id` fields in the received
message: it must not leak the hostname, nor the local IP.
+* Make sure Claws Mail use its dedicated `SocksPort` when connecting
+ to IMAP / POP3 / SMTP servers by monitoring the output of this
+ command:
+ sudo watch -n 0.1 'netstat -taupen | grep claws'
# WhisperBack
@@ -364,23 +175,6 @@ the appropriate tcpdump or tshark filters.
* When we receive this bug report on the tails-bugs mailing-list,
Schleuder tells us that it was sent encrypted.
-# Time
-(automate: [[!tails_ticket 5836]])
-1. Boot Tails without a network cable connected.
- (e.g. `virsh domif-setlink tails-dev 52:54:00:05:17:62 down`.)
-2. Set an administration password.
-3. set the time to an obviously wrong one:
- date --set="Mon, 01 Mar 2000 15:45:34 - 0800"
-4. Connect the network cable.
- (e.g. `virsh domif-setlink tails-dev 52:54:00:05:17:62 up`)
-=> the date should be corrected and Tor/Vidalia should start
# Erase memory on shutdown
- `memlockd` must be running
@@ -446,18 +240,6 @@ Start I2P by appending `i2p` to the kernel command line.
* The I2P router console should still be accessible on
-# Git
-* clone a repository over `git://`
- git clone git://
-* clone a repository over `https://`
- git clone
-* clone a repository over SSH
* Connecting over SSH to a server on the Internet should work (and
@@ -494,12 +276,18 @@ Start I2P by appending `i2p` to the kernel command line.
* For upgrade paths that only propose a full upgrade: make sure the
user is told to do a manual upgrade.
- If the IUKs and update-description files have been published on the
- *alpha* channel already (see
- <>):
+ If:
+ * the update-description files have been published on the
+ *alpha* channel already (see <>)
+ * and the IUK has been published already (see
+ <>
+ and <>):
- echo 'TAILS_CHANNEL="alpha"' | sudo tee --append /etc/os-release && \
- tails-upgrade-frontend-wrapper
+ then:
+ echo 'TAILS_CHANNEL="alpha"' | sudo tee --append /etc/os-release && \
+ tails-upgrade-frontend-wrapper
Else, use a local test setup:
@@ -540,21 +328,6 @@ Enable Windows camouflage via the Tails Greeter checkbox and:
* The Tor Browser should use a Internet Explorer theme
* The Unsafe Browser has no scary red theme
-# Unsafe Web Browser
-(automate: [[!tails_ticket 7823]])
-* On start, if no DNS server was configured in NetworkManager
- (e.g. if there's no network connection), there must be an error.
-* Once started, check that:
- - the Tor Browser instance runs as the `clearnet` user.
- - it has no proxy configured.
- - no extensions are installed.
- - there are no bookmarks except the default Firefox ones.
-* On exit, check that:
- - make sure that its chroot gets properly teared down on exit (there
- should be nothing mounted inside `/var/lib/unsafe-browser`).
# Real (non-VM) hardware
@@ -568,9 +341,10 @@ Enable Windows camouflage via the Tails Greeter checkbox and:
# Documentation
-* Check that links to the online website (`Mirror:`) at the bottom of
- bundled static web pages (`/usr/share/doc/tails/website/`) are working. Else, it probably means the
- wiki was not built with a recent enough ikiwiki.
+* The "Tails documentation" desktop launcher should open the
+ [[getting started]] page (automate: [[!tails_ticket 8788]]):
+ - in one language to which the website is translated
+ - in one language to which the website is not translated (=> English)
* Browse around in the documentation shipped in the image. Internal
links should be fine.
@@ -606,14 +380,12 @@ language. You *really* have to reboot between each language.
# Misc
* Check that Tails Greeter's "more options" screen displays properly
- on a display with 600 px height.
+ on a display with 600 px height, preferably in a language that's
+ more verbose than English (e.g. French).
* Check that all seems well during init (mostly that all services
start without errors), and that `/var/log/syslog` seems OK.
* MAT should be able to clean a PDF file, such as:
-* The Tails signing key shipped should be up-to-date (that is, neither it nor
- one its subkeys must have expired, or be about to expire any time soon).
- - `gpg --list-keys --with-colons 1202821CBE2CD9C1`
* The "Report an error" desktop launcher should open the [[support]]
page, both in English and in one language to which the website is
translated (automate: [[!tails_ticket 6904]]).
diff --git a/wiki/src/contribute/release_process/test/automated_tests.mdwn b/wiki/src/contribute/release_process/test/automated_tests.mdwn
index 22db600..e637935 100644
--- a/wiki/src/contribute/release_process/test/automated_tests.mdwn
+++ b/wiki/src/contribute/release_process/test/automated_tests.mdwn
@@ -25,6 +25,8 @@ the Sikuli programmatic interface from our step definitions.
See [[contribute/release_process/test/setup]] and [[contribute/release_process/test/usage]].
+Core developers can also run it [[usage/on_lizard]].
## Features
With this tool, it is possible to:
diff --git a/wiki/src/contribute/release_process/test/setup.mdwn b/wiki/src/contribute/release_process/test/setup.mdwn
index d9b35d4..5c9008a 100644
--- a/wiki/src/contribute/release_process/test/setup.mdwn
+++ b/wiki/src/contribute/release_process/test/setup.mdwn
@@ -20,14 +20,22 @@ wheezy-backports sources added:
echo -e "Package: *\nPin: release o=Debian,a=testing\nPin-Priority: 500" \
> /etc/apt/preferences.d/Debian_testing && \
apt-get update &&
- apt-get install git xvfb virt-viewer libsikuli-script-java \
+ apt-get install git i18nspector xvfb virt-viewer libsikuli-script-java \
libxslt1-dev tcpdump unclutter radvd x11-apps syslinux \
libcap2-bin devscripts libvirt-ruby ruby-rspec gawk ntp ovmf/testing \
ruby-json x11vnc xtightvncviewer ffmpeg libavcodec-extra-53 \
- libvpx1 dnsmasq-base openjdk-7-jre && \
+ libvpx1 dnsmasq-base openjdk-7-jre ruby-guestfs && \
apt-get -t wheezy-backports install qemu-kvm qemu-system-x86 libvirt0 \
libvirt-dev libvirt-bin seabios ruby-rjb ruby-packetfu cucumber && \
- service libvirt-bin restart
+ service libvirtd restart
+In addition, if `libguestfs` doesn't work by default you probably have
+hit [[!debbug 741203]], which still may affect Wheezy systems but it's
+verified to have been fixed in Debian Jessie. Then you must run (as
+ export excludes="--exclude ^openrc"
+ update-guestfs-appliance
Other requirements
diff --git a/wiki/src/contribute/release_process/test/usage.mdwn b/wiki/src/contribute/release_process/test/usage.mdwn
index 1535360..9376cee 100644
--- a/wiki/src/contribute/release_process/test/usage.mdwn
+++ b/wiki/src/contribute/release_process/test/usage.mdwn
@@ -1,5 +1,10 @@
[[!meta title="Running the automated test suite"]]
+[[!toc levels=2]]
+Basic usage
Use the `run_test_suite` script found in the Tails source root to run
all automated Cucumber test features. See the [[setup
documentation|test/setup]] in case you don't have a testing
@@ -31,3 +36,79 @@ For full instructions, see its `--help`.
Note: since the test suite itself uses `virt-viewer` to interact with
the Tails guest you cannot use it as that will steal the session from
the test suite, leaving it with a blank screen.
+The test suite can be configured in the following ways:
+1. `run_test_suite` parameters, which takes precedence over
+2. the local configuration file `features/config/local.yml`, which
+takes precedence over
+3. the default configuration file `features/config/defaults.yml`.
+However, some values are treated as secrets and have no
+defaults. These secrets are generally information about online sevices
+to be used in certain features, like host, port and credentials --
+stuff we don't want to make public. These must be set explicitly in
+order for those features to run.
+## Non-secret configuration
+Here's a list of all non-secret key-value pairs that can be supported
+by the local configuration file:
+* `DEBUG`: Boolean value. If set to `true`, various debugging info
+ will be printed. Defaults to `false`.
+* `PAUSE_ON_FAIL`: Boolean value. If set to `true`, the test suite run
+ is suspended on failure until ENTER is pressed. This is useful for
+ investigating the state of the VM guest to see exactly why a test
+ failed. Defaults to `false`.
+* `SIKULI_RETRY_FINDFAILED`: Boolean value. If set to `true`, print a
+ warning whenever Sikuli fails to find an image and allow *one* retry
+ after pressing ENTER. This is useful for updating outdated images,
+ or when extracting new images. Defaults to `false`.
+* `TEMP_DIR`: String value. Directory where various temporary files
+ are written during a test, e.g. VM snapshots and memory dumps,
+ failure screenshots, pcap files and disk images. Defaults to
+ `"/tmp/TailsToaster"`.
+## "Secret" configuration
+This section describes the formats for all secret configurations that
+must be configured in the local configuration file for certain
+features or scenarios to work. If any of these are omitted, parts of
+the test suite will fail.
+### Tor pluggable transports
+The format is:
+ Tor:
+ Transports:
+ $TYPE:
+ - ipv4_address: ""
+ ipv4_port: 443
+ fingerprint: "01234567890abcdef01234567890abcdef012345"
+ extra:
+ - ipv4_address: ""
+ [...]
+ - ipv4_address: ""
+ [...]
+where the type `$TYPE` (and `$ANOTHER_TYPE`) should be something like
+`Obfs4` or `Bridge` (the first type) or whatever Tor calls them. Both
+`fingerprint` and `extra` are optional and can be left empty (or
+skipped completely), but e.g. `extra` is necessary for `Obfs4` type
+bridges, for the `cert=... iat-mode=...` stuff, and the same for
+`Scramblesuite`'s `password=...`.
+This setting is required for `tor_bridges.feature` (requires types
+`Bridge`, `Obfs2`, `Obfs3` and `Obfs4`) and `time_syncing.feature`
+(requires type `Bridge` only).
diff --git a/wiki/src/contribute/release_process/test/usage/on_lizard.mdwn b/wiki/src/contribute/release_process/test/usage/on_lizard.mdwn
new file mode 100644
index 0000000..9d4d09d
--- /dev/null
+++ b/wiki/src/contribute/release_process/test/usage/on_lizard.mdwn
@@ -0,0 +1,29 @@
+[[!meta title="Running the automated test suite on lizard"]]
+The isotester1 VM on lizard is configured to run our automated test
+suite. Core Tails developers can run it there, e.g. on ISO images
+built by Jenkins.
+[[!toc levels=2]]
+# Entering the system
+As a core developer, you have SSH access to `isotester1.lizard`.
+The connection details you need live in our internal Git repository.
+# Getting an ISO image
+You can quickly retrieve ISO images built by Jenkins from
+<>, e.g. using `wget` or `curl`.
+# Running the test suite
+Use `sudo su -` to enter a root session.
+A clone of the Tails Git repository can be found in `/srv/git/`.
+When using the `--capture` option, please pass it a filename within
+`/tmp/TailsToaster`, for storage management reasons.
+You can access the VNC display of the system under testing using
+a SSH tunnel.
diff --git a/wiki/src/contribute/release_process/tor-browser.mdwn b/wiki/src/contribute/release_process/tor-browser.mdwn
index dcd8933..18f2266 100644
--- a/wiki/src/contribute/release_process/tor-browser.mdwn
+++ b/wiki/src/contribute/release_process/tor-browser.mdwn
@@ -1,5 +1,42 @@
[[!meta title="Releasing the Tor Browser"]]
+[[!toc levels=2]]
+The big picture
+The Tails ISO build system [[!tails_gitweb
+config/chroot_local-hooks/10-tbb desc="downloads"]] a set of Tor
+Browser tarballs from a location specified in [[!tails_gitweb
+config/chroot_local-includes/usr/share/tails/tbb-dist-url.txt]], and
+compares their hash with previously verified ones found in
+Once released officially, Tor Browser tarballs can be found in
+a [permanent (?)
+However, when upgrading Tor Browser for an imminent Tails release, we
+generally have to use Tor Browser tarballs that are under QA and not
+officially released yet. So, we have to retrieve them from another,
+temporary location, such as
+<>. If we hard-coded
+this temporary URL in `tbb-dist-url.txt`, then our release tag would
+only be buildable for as long the tarballs stay in that place, which
+at best is a few months.
+To solve this, we host ourselves the Tor Browser tarballs we need, and
+point to [this permanent
+location]( for anything that
+we tag.
+Still, one can set an arbitrary download location in
+`tbb-dist-url.txt`, which should provide all the flexibility needed
+for development purposes.
+Upgrade Tor Browser in Tails
Have a look at
* <>
@@ -7,16 +44,15 @@ Have a look at
* <>
* <>
-and see if the desired version is available. We prefer
-`` since the other sources periodically cleans
-up old releases. Set `DIST_URL` to the chosen url, and set `VERSION`
-to the desired TBB version, for example:
+and see if the desired version is available. Set `DIST_URL` to the
+chosen URL, and set `VERSION` to the desired Tor Browser version, for
-Fetch the version's `sha256sums.txt` and `sha256sums.txt.asc` and
-verify with `gpg`:
+Fetch the version's hash file and its detached signature, and verify
+with GnuPG:
wget ${DIST_URL}/${VERSION}/sha256sums.txt{,.asc} && \
gpg --verify sha256sums.txt.asc sha256sums.txt
@@ -24,20 +60,98 @@ verify with `gpg`:
Filter the tarballs we want and make them available at build time,
when the tarballs are fetched:
- grep "\<tor-browser-linux32-.*\.tar.xz$" sha256sums.txt > \
+ grep --color=never "\<tor-browser-linux32-.*\.tar.xz$" sha256sums.txt > \
-Then update the url to the one chosen above:
+Then update the URL to the one chosen above:
echo "${DIST_URL}" | sed "s,^https://,http://," > \
-NOTE: We must use http (not http**s**) due to limitations/bugs in
-`apt-cacher-ng`, which often is used in Tails build
+<div class="note">
+We cannot use HTTPS due to limitations/bugs in
+<code>apt-cacher-ng</code>, which often is used in Tails build
environments. However, it is of no consequence since we verify the
checksum file.
Lastly, commit:
git commit config/chroot_local-includes/usr/share/tails/tbb-*.txt \
- -m "Upgrade TBB to ${VERSION}."
+ -m "Upgrade Tor Browser to ${VERSION}."
+<div class="caution">
+If this new Tor Browser is meant to be included in a Tails
+release, then that's not enough: as explained above, we need to host
+the corresponding tarballs ourselves, so read on the next section.
+Self-hosted Tor Browser tarballs archive
+Initial setup
+First, install git-annex from wheezy-backports or newer.
+Then, make sure you have an entry for `` in
+your `~/.ssh/config`. See systems/ISO_history in the internal Git repo
+for details.
+Then, clone the metadata repository and initialize git-annex:
+ git clone && \
+ cd torbrowser-archive && \
+ git annex init
+You now have a lot of (broken) symlinks in place of the files that are
+available in this git-annex repo.
+To synchronize your git-annex metadata with the remote, run:
+ git annex sync
+Import a new set of Tor Browser tarballs
+1. Make `TAILS_GIT_REPO` point to the main Tails Git repository
+ checkout where `tbb-dist-url.txt` is being worked on, for example:
+ TAILS_GIT_REPO="$HOME/tails/git"
+2. Tell git-annex to record each tarball's URL into Git:
+ cat "${TAILS_GIT_REPO}/config/chroot_local-includes/usr/share/tails/tbb-sha256sums.txt" | \
+ while read expected_sha256 tarball; do
+ git annex addurl --fast --pathdepth=-2 \
+ "$(cat "${TAILS_GIT_REPO}/config/chroot_local-includes/usr/share/tails/tbb-dist-url.txt")/${VERSION}/${tarball}"
+ done
+Commit and push your changes
+ git commit -m "Add Tor Browser ${VERSION}." && \
+ git annex sync && \
+ git annex copy --to origin
+Adjust the URL in the main Git repository
+ cd "$TAILS_GIT_REPO" && \
+ echo '' > \
+ config/chroot_local-includes/usr/share/tails/tbb-dist-url.txt && \
+ git commit config/chroot_local-includes/usr/share/tails/tbb-dist-url.txt \
+ -m "Fetch Tor Browser from our own archive."
+Wait for the synchronization
+Once you've gone through these steps, a cronjob that runs every
+5 minutes will download the tarballs and make them available on
+Wait for this to happen before you can build Tails using the new URL.
diff --git a/wiki/src/contribute/release_process/tor.mdwn b/wiki/src/contribute/release_process/tor.mdwn
new file mode 100644
index 0000000..7189408
--- /dev/null
+++ b/wiki/src/contribute/release_process/tor.mdwn
@@ -0,0 +1,51 @@
+[[!meta title="Releasing liveusb-creator"]]
+[[!toc levels=1]]
+Note: we're _not_ using Git, as weasel's script do lots of clever
+things between the Git tree and the source package. So let's simply
+take whatever he has uploaded to Debian and build it against
+wheezy-backports, to get seccomp support.
+1. Make sure you have Debian unstable APT deb-src sources configured.
+2. Make sure you have an up-to-date wheezy-backports i386 pbuider chroot.
+3. Download the source package from Debian unstable, extract it, cd
+ into the directory:
+ WORKDIR=$(mktemp -d)
+ cd "$WORKDIR" && \
+ apt-get source tor/unstable && \
+ cd tor-*
+4. Set `$DISTRIBUTION` to the name of the Tails APT suite you'll want
+ to upload to, e.g.:
+ DISTRIBUTION=feature-tor-custom-build
+5. Update `debian/changelog`:
+ UNSTABLE_VERSION=$(dpkg-parsechangelog --count 1 -SVersion)
+ dch --newversion "$TAILS_VERSION" --force-bad-version \
+ --distribution "$DISTRIBUTION" --force-distribution \
+ "Rebuild on wheezy-backports to get seccomp support"
+ Check the resulting `debian/changelog` entry.
+6. Build in your wheezy-backports i386 chroot.
+7. Tweak the resulting `.changes` file so that it includes the
+ upstream tarball:
+ changestool *.changes includeallsources
+8. Sign the resulting package:
+ debsign $CHANGES_FILE
+9. Upload the resulting package:
+ dupload --to tails $CHANGES_FILE
diff --git a/wiki/src/contribute/working_together/code_of_conduct.mdwn b/wiki/src/contribute/working_together/code_of_conduct.mdwn
new file mode 100644
index 0000000..b238f21
--- /dev/null
+++ b/wiki/src/contribute/working_together/code_of_conduct.mdwn
@@ -0,0 +1,76 @@
+[[!meta title="Code of conduct"]]
+Like the technical community as a whole, the Tails team and community
+is made up of a mixture of people from all over the world, working on
+every aspect of the mission &mdash; including mentorship, teaching, and
+connecting people.
+Diversity is one of our huge strengths, but it can also lead to
+communication issues and unhappiness. To that end, we have a few
+ground rules that we ask people to adhere to when they're
+participating within this community and project. These rules apply
+equally to founders, mentors and those seeking help and guidance.
+This isn't an exhaustive list of things that you can't do. Rather,
+take it in the spirit in which it's intended &mdash; a guide to make it
+easier to enrich all of us and the technical communities in which
+we participate.
+This policy applies to all spaces used by the Tails project. This
+includes IRC, the mailing lists, the issue tracker, the website,
+events, and any other forums which the community uses for
+If you believe someone is violating this policy, we ask that you
+report it by emailing <>
+* **Be welcoming, friendly, and patient.**
+* **Be considerate.** Your work will be used by other people, and you
+ in turn will depend on the work of others. Any decision you take
+ will affect users and other contributors, and you should take those
+ consequences into account when making decisions. Remember that we're
+ a world-wide community, so you might not be communicating in someone
+ else's primary language.
+* **Be respectful.** Not all of us will agree all the time, but
+ disagreement is no excuse for poor behavior and poor manners.
+ We might all experience some frustration now and then, but we cannot
+ allow that frustration to turn into a personal attack. It's
+ important to remember that a community where people feel
+ uncomfortable or threatened is not a productive one. Members of the
+ Tails community should be respectful when dealing with other members
+ as well as with people outside the Tails community.
+* **Be careful in the words that you choose.** Be kind to others.
+ Do not insult or put down other participants. Harassment and other
+ exclusionary behavior aren't acceptable. This includes, but is not
+ limited to:
+ - Violent threats or language directed against another person.
+ - Sexist, racist, or otherwise discriminatory jokes and language.
+ - Exhibiting sexually explicit or violent speak or material.
+ - Publishing (or threatening to publish) other people's personally
+ identifying information ("doxing").
+ - Recording, photographing or filming other persons without their
+ consent. Seek consent before recording. Also ask people who may be
+ seen or heard in the background. Similarly, don't publish private
+ communication without asking first, except if the communication
+ was unwanted (harrassment, threats etc). In doubt, you can ask us
+ before publishing something.
+ - Personal insults, especially those using racist or sexist terms.
+ - Unwelcome sexual attention.
+ - Advocating for, or encouraging, any of the above behavior.
+ - Repeated harassment of others. In general, if someone asks you to
+ stop, then stop.
+* **When we disagree, try to understand why.** Disagreements, both
+ social and technical, happen all the time and Tails is no exception.
+ It is important that we resolve disagreements and differing views
+ constructively. Remember that we're different. The strength of Tails
+ comes from its varied community, people from a wide range of
+ backgrounds. Different people have different perspectives on issues.
+ Being unable to understand why someone holds a viewpoint doesn't
+ mean that they're wrong. Don't forget that it is human to err and
+ blaming each other doesn't get us anywhere. Instead, please consider
+ offering your help in order to resolve issues and to help learn
+ from mistakes.
+Adapted from the [Django Code of
+Conduct](, that itself
+attributes it to the [Speak Up! project](
diff --git a/wiki/src/contribute/working_together/document_progress.mdwn b/wiki/src/contribute/working_together/document_progress.mdwn
index d2b4fa2..075c794 100644
--- a/wiki/src/contribute/working_together/document_progress.mdwn
+++ b/wiki/src/contribute/working_together/document_progress.mdwn
@@ -4,11 +4,24 @@
When a developer works on a task, she should create/update a ticket related to
the task. All the knowledge useful to the others should be kept there (or at
-least linked from there). She should take care of updating the tags of the
-ticket so that they reflect the actual status of the task and especially the
+least linked from there). She should take care of updating this ticket's
+properties so that they reflect the actual status of the task, and especially the
next thing to do for it to be solved.
-The tickets are currently stored in [[!tails_redmine "" desc="Redmine"]].
+The tickets are stored in [[!tails_redmine "" desc="Redmine"]].
+When committing changes that will resolve a ticket once merged, please
+consider including `will-fix: #NNNN` in the commit message, _NNNN_
+being the ticket number. Then, Redmine will automatically flag the
+corresponding ticket as "In Progress" once the branch is pushed to our
+main [[Git repository|contribute/Git]]. For example:
+ Remove duty from frontdesk (Will-fix: #8420)
+This keyword should be used only in topic branches, or when committing
+directly in the master branch. When merging topic branches into
+development branches, you should used the [[`fix-committed`|merge_policy#fix-committed]] keyword
# Report progress or failure
diff --git a/wiki/src/contribute/working_together/roles/front_desk.mdwn b/wiki/src/contribute/working_together/roles/front_desk.mdwn
index 7a330e0..6bc85f4 100644
--- a/wiki/src/contribute/working_together/roles/front_desk.mdwn
+++ b/wiki/src/contribute/working_together/roles/front_desk.mdwn
@@ -29,22 +29,3 @@ General communication watchdog
- [](
- [](
- [](
- - If also subscribed to
- - Forward user support emails received on to
- - Forward press requests received on to
- - Reply other random incoming emails on
-Meetings management
- - Announce public meetings and low-hanging fruits sessions on:
- * Twitter
- * [Tor Weekly News]( (follow the *Next steps* link)
- - Write report of low-hanging fruits sessions, and send it to tails-dev@ if attended.
- - Write & publish the minutes of the public meeting if attended.
- - Explain in details the decisions that were taken.
- - Keep track of the brainstorming that we did if no decision was taken.
- - Include names of people who took responsibilities.
- - Update Redmine tickets accordingly and point them to the meeting notes
- (unless someone else volunteers to do it on some tickets).
- - Publish the monthly report.
diff --git a/wiki/src/contribute/working_together/roles/release_manager.mdwn b/wiki/src/contribute/working_together/roles/release_manager.mdwn
index c532fe0..0e7b4d9 100644
--- a/wiki/src/contribute/working_together/roles/release_manager.mdwn
+++ b/wiki/src/contribute/working_together/roles/release_manager.mdwn
@@ -4,9 +4,11 @@
## In the beginning of your shift
+- Check the Mozilla release calendars:
+ * [Google calendar](
+ * [Release schedule](
- Send the release schedule to <> and
- <>. Use the [Mozilla release
- calendar](
+ <>.
Ask the core team and contributors for availability at the
dates designated for testing the RC and final image.
- Update [[contribute/calendar]] accordingly.
@@ -15,6 +17,16 @@
if needed.
- Make sure you have access to the various systems used to do
the release.
+- Check when the SSL certificate for expires.
+ If that's before, or soon after, the scheduled date for the release
+ _after_ the one your shift is about, then:
+ * Get in touch with <> to know about their plans.
+ * Create a ticket for the release your shift is about, so that we
+ update the CA bundle that's used by Tails Upgrader and the
+ security check.
+- Check when our OpenPGP signing key expires.
+ If that's before, or soon after, the scheduled date for the release
+ _after_ the one your shift is about, then shout.
## Around two weeks before the freeze
@@ -22,6 +34,8 @@
in [Torbutton](, and
do whatever is needed to get the fixes we need in the release.
- Have Kill Your TV upgrade I2P if needed. See [[contribute/design/I2P]].
+- If needed, update the list of Tor authorities in the test
+ suite configuration.
## Continuously
diff --git a/wiki/src/contribute/working_together/roles/sysadmins.mdwn b/wiki/src/contribute/working_together/roles/sysadmins.mdwn
index d218743..5a70e86 100644
--- a/wiki/src/contribute/working_together/roles/sysadmins.mdwn
+++ b/wiki/src/contribute/working_together/roles/sysadmins.mdwn
@@ -117,6 +117,18 @@ We use Redmine tickets for public discussion and tasks management:
* configuration: `tails::gitolite` class in [[!tails_gitweb_repo
+## git-annex
+* purpose: host the full history of Tails released images and Tor
+ Browser tarballs
+* access: Tails core developers only
+* tools: [[!debpts git-annex]]
+* configuration:
+ - `tails::git_annex` and `tails::gitolite` classes in
+ [[!tails_gitweb_repo puppet-tails]]
+ - `tails::git_annex::mirror` defined resource in
+ [[!tails_gitweb_repo puppet-tails]]
## Jenkins
* purpose: continuous integration, e.g. build Tails ISO images from
@@ -157,7 +169,7 @@ We use Redmine tickets for public discussion and tasks management:
for testing
* access: anyone who gets it from
-* tools: [[!debpts tor]], [[!debpts obfsproxy]]
+* tools: [[!debpts tor]], [[!debpts obfs4proxy]]
* configuration:
- `tails::apt::repository::torproject` in
[[!tails_gitweb_repo puppet-tails]]