path: root/wiki/src/contribute/release_process
diff options
Diffstat (limited to 'wiki/src/contribute/release_process')
8 files changed, 335 insertions, 274 deletions
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