summaryrefslogtreecommitdiffstats
path: root/wiki/src/contribute/release_process
diff options
context:
space:
mode:
Diffstat (limited to 'wiki/src/contribute/release_process')
-rw-r--r--wiki/src/contribute/release_process/Debian_security_updates.mdwn11
-rw-r--r--wiki/src/contribute/release_process/iceweasel.mdwn479
-rw-r--r--wiki/src/contribute/release_process/test.mdwn112
-rw-r--r--wiki/src/contribute/release_process/test/automated_tests.mdwn2
-rw-r--r--wiki/src/contribute/release_process/test/erase_memory_on_shutdown.mdwn12
-rw-r--r--wiki/src/contribute/release_process/test/erase_memory_on_shutdown/qemu_pmemsave.mdwn4
-rw-r--r--wiki/src/contribute/release_process/test/setup.mdwn26
-rw-r--r--wiki/src/contribute/release_process/test/usage.mdwn2
-rw-r--r--wiki/src/contribute/release_process/tor-browser.mdwn43
9 files changed, 153 insertions, 538 deletions
diff --git a/wiki/src/contribute/release_process/Debian_security_updates.mdwn b/wiki/src/contribute/release_process/Debian_security_updates.mdwn
index f0d696c..06bdaf3 100644
--- a/wiki/src/contribute/release_process/Debian_security_updates.mdwn
+++ b/wiki/src/contribute/release_process/Debian_security_updates.mdwn
@@ -5,17 +5,6 @@ by delaying a Tails release a bit to wait for a DSA to happen.
[[!toc levels=2]]
-Iceweasel
-=========
-
-Mozilla updates are scheduled in advance. Searching the web for the
-next (point-)release number tells you when it will be released. Add
-2-3 days to this release date, and you know when a xulrunner/iceweasel
-Debian security update will be ready on the mirrors.
-
-See the [releases page](http://wiki.mozilla.org/Releases) on Mozilla
-wiki.
-
Debian security team
====================
diff --git a/wiki/src/contribute/release_process/iceweasel.mdwn b/wiki/src/contribute/release_process/iceweasel.mdwn
deleted file mode 100644
index 21abb5e..0000000
--- a/wiki/src/contribute/release_process/iceweasel.mdwn
+++ /dev/null
@@ -1,479 +0,0 @@
-[[!meta title="Releasing Iceweasel + Torbrowser patches"]]
-
-[[!toc levels=2]]
-
-1. Prepare environment
-======================
-
-* Clone the Tor browser
- [[Git repository|contribute/git#other-repositories]] if you do not
- have it handy yet.
-
-* Add (and fetch from) a Git remote for the Debian iceweasel packaging
- repository:
-
- git remote add -f debian git://git.debian.org/git/pkg-mozilla/iceweasel.git
-
-* Export the new upstream release to the environment of the one shell
- or three that will be used:
-
- export VERSION=17.0.9esr
-
-2. Was Iceweasel updated?
-=========================
-
-It might have been updated in one of these sources:
-
-* branch `esr/master` in `git://git.debian.org/git/pkg-mozilla/iceweasel.git`
-* <http://mozilla.debian.net/pool/iceweasel-esr/i/iceweasel/>
-
-**If** it was updated, then skip to [[New Iceweasel release|iceweasel#new-iceweasel-release]].
-**Else**, skip to [[New Firefox release|iceweasel#new-firefox-release]].
-
-<a id="new-firefox-release"></a>
-
-3. New Firefox release
-======================
-
-If Iceweasel was not updated to match the new Firefox release we want,
-a bit more work is needed.
-
-Note that usually, we're doing these steps (usually on Sunday or
-Monday) *before* the new ESR was officially released (which usually
-happens on Tuesday). Mozilla make the source available on previous
-Friday or Saturday, so that downstreams (such as us!) can get their
-stuff ready in time for the security announce.
-
-* Download the Firefox tarball and detached signature from
- <https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/VERSION/source/>
- (`VERSION` is the version we want to build, that is something like
- `17.0.7esr`).
- If it's not ready there yet, look at
- <https://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/VERSION-candidates/>
- instead: Mozilla now only moves the tarballs to the `releases` directory after
- it has passed their internal QA.
-* Check the signature.
-* Put the tarball in the parent directory of your Iceweasel Git repository.
-* Extract the tarball.
-* `cd` into the extracted directory.
-* Copy the `debian/` directory from our previous package into the new
- upstream source directory.
-* Add a `debian/changelog` entry matching the new
- upstream version. Use 0 for the Debian packaging version, e.g.
- `17.0.5esr-0`, to leave room for the official packaging that we will
- want to merge when it's out:
-
- dch -v ${VERSION}-0 "New upstream release."
-
-* If you had to download a *candidate* version above, patch
- `debian/upstream.mk` so that it downloads stuff from the same place,
- e.g.:
-
- --- a/debian/upstream.mk
- +++ b/debian/upstream.mk
- @@ -89,12 +89,12 @@ ifndef L10N_CHANNEL
- L10N_CHANNEL := $(SOURCE_CHANNEL)
- endif
-
- -BASE_URL = ftp://ftp.mozilla.org/pub/mozilla.org/$(PRODUCT_NAME)/$(SOURCE_TYPE)
- +BASE_URL = ftp://ftp.mozilla.org/pub/mozilla.org/$(PRODUCT_NAME)/candidates
-
- L10N_FILTER = awk '(NF == 1 || /linux/) && $$1 != "en-US" { print $$1 }'
- $(call lazy,L10N_LANGS,$$(shell $$(L10N_FILTER) $(PRODUCT)/locales/shipped-locales))
- ifeq ($(SOURCE_TYPE),releases)
- -SOURCE_URL = $(BASE_URL)/$(SOURCE_VERSION)/source/$(PRODUCT_NAME)-$(SOURCE_VERSION).source.tar.bz2
- +SOURCE_URL = $(BASE_URL)/$(SOURCE_VERSION)-candidates/build1/source/$(PRODUCT_NAME)-$(SOURCE_VERSION).source.tar.bz2
- SOURCE_REV = $(call uc,$(PRODUCT_NAME))_$(subst .,_,$(SOURCE_VERSION))_RELEASE
- L10N_REV = $(SOURCE_REV)
- SOURCE_REPO = http://hg.mozilla.org/releases/$(SOURCE_CHANNEL)
-
- **Beware**: make sure to replace `build1` with the name of the
- directory you downloaded the upstream candidate tarball above.
-
-* Download and repack the other tarballs:
-
- make -f debian/rules download
-
-* `cd` into our Iceweasel Git directory.
-* Checkout the `tails/master` branch.
-* Unapply all quilt patches and commit:
-
- quilt pop -a && \
- git add . && git reset HEAD .pc && git commit -a -m 'Unapply all quilt patches.'
-
-* Get yourself a new upstream branch:
-
- git branch -D upstream && \
- git branch upstream tails/master
-
-* Trick the tarball importer to import the correct version:
-
- cp ../mozilla-esr24/browser/config/version.txt browser/config/ && \
- cp ../mozilla-esr24/debian/changelog debian/
-
-* Import the new upstream release into the `upstream` branch:
-
- make -f debian/rules import
-
-* Merge the import commit into `tails/master`:
-
- git reset --hard && git merge upstream
-
-* Get the `debian` directory back:
-
- git checkout HEAD^ -- debian && \
- git commit -m 'Get Debian packaging directory back.'
-
-* Don't ignore `.mozconfig`'s:
-
- grep -v -F '/.mozconfig*' .gitignore | sponge .gitignore && \
- git commit -m "Don't ignore .mozconfig's." .gitignore
-
-* Cleanup quilt status:
-
- rm -rf .pc
-
-* Apply all quilt patches:
-
- quilt push -a
-
- It might be that the last patch (`configure.patch`) fails. Ignore it
- for now.
-
-* Commit:
-
- git add . && git reset HEAD .pc && git commit -a -m 'Apply all quilt patches.'
-
-<a id="new-iceweasel-release"></a>
-
-4. New Iceweasel release
-=========================
-
-Skip this entire stage if you imported a new Firefox release.
-
-The way to proceed is different depending on whether Debian's
-iceweasel was pushed to it yet, or not.
-
-If Debian's iceweasel was pushed to Git already
------------------------------------------------
-
-* Retrieve the update from the iceweasel Git repository and verify the
- Git tag you want to import, e.g.
-
- git fetch debian && git tag -v debian/17.0.8esr-1
-
-* Checkout our `tails/master` branch.
-
-* Unapply all Torbrowser patches:
- - If quilt knows they are applied (`quilt applied` will tell you),
- then use `quilt pop` as many times as needed.
- - Else, some manual care is needed so that quilt internal state
- matches the actual state of the source tree. We need to manually
- unapply all quilt patches, then reapply them all:
-
- for p in $(tac debian/patches/series) ; do
- patch -p1 -R < "debian/patches/$p"
- done && quilt push -a
-
- ... and then use `quilt pop` as many times as needed to unapply
- all Torbrowser patches.
-
-* `git add` the new files and the modified ones
-
-* `git rm` the deleted files
-
-* Commit:
-
- git commit -m 'Remove Torbrowser patches.'
-
-* Merge the tag, e.g.
-
- git merge debian/17.0.8esr-1
-
-* Verify with that `tails/master` is in the same state as Debian's
- iceweasel, e.g.
-
- git diff --stat debian/17.0.8esr-1..tails/master
-
- All expected differences should be:
- * files modified: `.gitignore`,
- `debian/{changelog,rules,control,control.in}`,
- `debian/{browser.mozconfig,xulrunner.mozconfig.in}`
- * files added: `.mozconfig*`, `debian/tails.*.mozconfig`,
- `debian/patches/series`, and the Torbrowser patches.
-
-If Debian's iceweasel was not pushed to Git yet
------------------------------------------------
-
-Then, we have to import the source package into Git ourselves, and
-merge from Debian's Vcs-Git later.
-
-* Download, verify and extract the new iceweasel source package with dget.
-
-* Checkout our `tails/master` branch.
-
-* Unapply all quilt patches and commit:
-
- quilt pop -a
-
-* `git rm` the deleted files
-
-* `git add` the new files and the modified ones
-
-* Commit:
-
- git commit -m 'Remove all quilt patches.'
-
-* Overwrite the files in the Git checkout with the new ones.
- Assuming the new extracted iceweasel package is in
- `iceweasel-17.0.2esr`, and our iceweasel Git repository checkout is
- in `git`:
-
- rsync --stats -a --exclude=.git --delete iceweasel-17.0.2esr/ git/
-
-* `git rm` the deleted files
-
-* `git add *`
-
-* Add other added or modified files *but* `.pc`.
-
-* Commit:
-
- git commit -m "Import $(head -n 1 debian/changelog | sed -e 's,).*,),')"
-
-* Verify with `diff` that the current state of the `tails/master` is
- exactly the same as Debian's iceweasel source package one:
-
- diff -Naur --exclude=.git iceweasel-17.0.2esr/ git/
-
-* Bring our changes back:
- * files modified: `.gitignore`,
- `debian/{changelog,rules,control,control.in}`,
- `debian/{browser.mozconfig,xulrunner.mozconfig.in}`
- * files added: `.mozconfig*`, `debian/tails.*.mozconfig`,
- `debian/patches/series`, and the Torbrowser patches.
-
-5. Update Torbrowser patches
-============================
-
-First, check if the Torbrowser patches were updated since the last
-time we imported them (that's why we always record in
-`debian/changelog` the TorBrowser Git commit we are importing from).
-
-**If** the Torbrowser patches were not updated, then just apply them
-and commit:
-
- quilt push -a && git commit -a -m 'Apply Torbrowser patches.'
-
-... then skip this entire stage.
-
-**Else**, proceed with the following steps.
-
-* Make sure all quilt patches are applied.
-* Unapply all Torbrowser patches: use `quilt pop` as many times as
- needed.
-* Revert our changes (with `--no-commit`) to
- `debian/patches/configure.patch` if needed, and deapply it:
-
- cat debian/patches/configure.patch | patch -p1 --reverse
-
-* `quilt delete` the `configure.patch` if it exists.
-
-* Remove all Torbrowser patches from the series:
-
- quilt unapplied | grep --color=never '^torbrowser/' | xargs -n 1 quilt delete
-
-* Remove Torbrowser patches from Git:
-
- git rm -r debian/patches/torbrowser/
-
-* Commit:
-
- git commit -a -m 'Remove Torbrowser patches.'
-
-* Import the latest TorBrowser patches:
-
- - Ensure you have Mike Perry's latest stuff available:
-
- git remote add -f mikeperry https://git.torproject.org/user/mikeperry/tor-browser.git
- git remote add -f ttp https://git.torproject.org/tor-browser.git
-
- - Find the most recent commit in ttp/tor-browser-24.2.0esr-1
- that is an import from Mozilla (see e.g. 5175d069); save its ID:
-
- export LAST_MOZILLA_COMMIT=XXX
-
- - Export the Torbrowser patches:
-
- TORBROWSER_PATCHES_DIR=$(mktemp -d)
- git format-patch -o "$TORBROWSER_PATCHES_DIR" \
- "$LAST_MOZILLA_COMMIT..ttp/tor-browser-$VERSION-3.x-1"
-
- - Remove from $TORBROWSER_PATCHES_DIR the patches we don't want.
- See `debian/changelog` for the - list of patches skipped last
- time, see the TorBrowser Git log to make your opinion about new or
- updated patches, use common sense. Take note of your decisions and
- its rationale, you will need it later.
-
- - Import the Torbrowser patches:
-
- for patch in $(\ls --reverse ${TORBROWSER_PATCHES_DIR}/*.patch) ; do
- p=$(basename "$patch")
- quilt import -P "torbrowser/$p" "$patch"
- done
- git add debian/patches/torbrowser debian/patches/series && \
- TORBROWSER_COMMIT=$(git rev-parse ttp/tor-browser-$VERSION-3.x-1)
- git commit -m "Import Torbrowser patches at commit ${TORBROWSER_COMMIT}."
-
-* Apply Torbrowser patches:
-
- quilt push -a && git add . && git reset HEAD .pc && git commit -a -m 'Apply Torbrowser patches.'
-
-* Update `debian/tails.*.mozconfig`:
- - copy all `ac_add_options` lines from `.mozconfig` into the *Tor
- Browser's options* section in `debian/tails.common.mozconfig`,
- *but* the ones that break the xulrunner build, that go into *Tor
- Browser's options specific to the browser component* section in
- `debian/tails.browser.mozconfig` instead
- - review the changes to these settings
- - if needed, update the `debian/tails.common.mozconfig`'s *Override
- Tor Browser's options* section
-
-* Push to Git:
-
- git push origin tails/master && git push --tags
-
-6. Build packages
-=================
-
-Update debian/changelog
------------------------
-
-* set a version such as `17.0.5esr-0+tails1`, e.g.
-
- dch -v "${VERSION}-0+tails1"
-
-* list our changes, especially the TorBrowser commit at which the
- patches were imported, and the ones we skipped
-* set distribution to unstable
-* commit:
-
- git commit debian/changelog \
- -m "$(head -n 1 debian/changelog | sed -e 's,).*,),')"
-
-Tag the release
----------------
-
- DEB_VERSION=$(dpkg-parsechangelog -SVersion)
- git tag -s -m "$(head -n 1 debian/changelog | sed -e 's,).*,),')" "debian/${DEB_VERSION}"
-
-Clean up the source tree
-------------------------
-
- git clean -fdx -e /.pc/
-
-Build for unstable
-------------------
-
-If you have no available non-Tails setup to comfortably test these
-packages, then skip this step.
-
-* Build for unstable and the architecture you can test on (most likely
- amd64), e.g. using our [[contribute/Debian_package_builder]].
- **Note:** if building locally in a ramdisk, it needs to be at least
- 14GB large.
-* Copy `browser/app/profile/000-tor-browser.js` into
- `/etc/iceweasel/pref/` on the test system.
-* Install and test the resulting packages.
-
-Build for wheezy-backports
---------------------------
-
-* Checkout the `tails/wheezy` branch and merge the tag:
-
- git checkout tails/wheezy && git merge "debian/${DEB_VERSION}"
-
-* Add a wheezy-backport changelog entry:
-
- dch --bpo
-
- Adjust as needed.
-
-* Commit:
-
- git commit debian/changelog \
- -m "$(head -n 1 debian/changelog | sed -e 's,).*,),')"
-
-* Tag the backport:
-
- git tag -s -m "$(head -n 1 debian/changelog | sed -e 's,).*,),')" \
- "debian/$(dpkg-parsechangelog -SVersion | sed -e 's,~,_,')"
-
-* Build for wheezy-backports and i386, e.g. using our
- [[contribute/Debian_package_builder]]. You may also do it yourself
- using `pbuilder`. Note that this repo is *not* adapted to be built
- with `git-buildpackage` or `git-pbuilder`.
-* Integrate these debs into your apt-cacher cache. That's one cp to
- `/var/cache/apt-cacher-ng/_import/` away, + 1 click in the
- web interface.
-* Test the resulting packages in Tails.
-* Make sure the `.orig.*` tarballs are included in the `.changes`
- file. FIXME: check if that's needed, or done automatically by the
- above instructions.
-* Upload the resulting packages to the relevant suite of our
- [[contribute/APT repository]].
-* Merge this APT suite where you need it: generally, that's `devel`,
- `experimental`, one of `stable` or `testing`, and maybe
- a release tag.
-* Push to Git:
-
- git push origin tails/wheezy && git push --tags
-
-Import bundled preferences
---------------------------
-
-* Copy `browser/app/profile/000-tor-browser.js` from the tag the
- Wheezy backport was built from, into
- `config/chroot_local-includes/etc/iceweasel/pref/`.
-* Commit this to the branch that is being used to prepare the release:
- ideally, a topic branch that will be reviewed and merged; in
- practice, more likely this will be `stable` or `testing`.
-
-7. Potential problems (and solutions)
-=====================================
-
-Problems with ./configure
--------------------------
-
-E.g. `configure.patch` does not apply, or the build fails since
-`{js/src/,}configure.in` was modified but `{js/src/,}configure` was
-not refreshed.
-
-In a nutshell, the solution is to:
-
-1. Make sure the patches that modify `{js/src/,}configure.in` are
- applied (this is the case after a `quilt push -a`, that is during
- most of the steps documented above).
-
-1. Update `{js/src/,}configure`:
-
- sudo apt-get install autoconf2.13
- make -f client.mk configure
-
- The `make` command may fail due to missing dependencies. We don't
- care, as long as `{js/src/,}configure` have been refreshed.
-
-1. Replace `configure.patch` with the diff between the original and
- updated version of `{js/src/,}configure`:
-
- configure_diff=$(mktemp) && \
- git diff configure js/src/configure > "$configure_diff" && \
- git reset --hard && \
- git clean -fdx -e /.pc/ && \
- quilt import -f -P configure.patch "$configure_diff" && \
- git commit debian/patches -m "Refresh configure.patch." && \
- quilt push && \
- git commit -a -m 'Apply configure.patch.'
-
-Note that `configure.patch` must always be the *last* patch in the
-quilt series file, after the TorBrowser ones.
diff --git a/wiki/src/contribute/release_process/test.mdwn b/wiki/src/contribute/release_process/test.mdwn
index 4159c14..9f3c93d 100644
--- a/wiki/src/contribute/release_process/test.mdwn
+++ b/wiki/src/contribute/release_process/test.mdwn
@@ -73,7 +73,7 @@ implemented, but it either hasn't been reviewed, had a confirmed pass
by someone other than the test author, or has issues. The latter is
tracked by tickets prefixed with `todo/test_suite:`.
-# Iceweasel
+# Tor Browser
## Security and fingerprinting
@@ -94,7 +94,7 @@ tracked by tickets prefixed with `todo/test_suite:`.
`ifconfig | grep inet | grep -v inet6 | cut -d" " -f2 | tail -n1`
* One should be able to switch identities from the web browser.
* Running `getTorBrowserUserAgent` should produce the User-Agent set by the
- installed version of Torbutton, and used in Iceweasel.
+ installed version of Torbutton, and used in the Tor Browser.
## Functionality
@@ -103,13 +103,18 @@ tracked by tickets prefixed with `todo/test_suite:`.
# Pidgin
-* Check that an IRC session is really torified:
- - if you are running an IRC server: check there
- - else: see if the connection to the IRC server appears in Vidalia
- connections list
+(automate: [[!tails_ticket 7820]])
+
* Check that you can initiate an OTR conversation.
-* Check that IRC is working with the default OFTC profile.
* Check that XMPP is working with a new test profile.
+ For example using Riseup:
+ - Username: username
+ - Domain: riseup.net
+ - Connect server: 4cjw6cwpeaeppfqz.onion
+ - Then try to create and connect to a new room:
+ - Room: testing
+ - Server: conference.riseup.net
+ - Handle: username
* Check that Pidgin doesn't leak too much information when replying to
CTCP requests:
* Start Tails, launch Pidgin, and join #tails.
@@ -128,6 +133,8 @@ 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 <http://deb.torproject.org/torproject.org/pool/main/t/tor/>.
* Check that the firewall-level Tor enforcement is effective:
@@ -253,11 +260,11 @@ the appropriate tcpdump or tshark filters.
sudo watch -n 0.1 'netstat -taupen | grep perl'
-* Make sure iceweasel uses its dedicated `SocksPort`: quit Iceweasel
+* 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 iceweasel'
+ sudo watch -n 0.1 'netstat -taupen | grep firefox'
* Make sure other applications use the default system-wide
`SocksPort`:
@@ -307,6 +314,8 @@ the appropriate tcpdump or tshark filters.
# 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,
@@ -357,6 +366,8 @@ the appropriate tcpdump or tshark filters.
# 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.
@@ -395,27 +406,56 @@ correctly.
# I2P
-* Make sure that I2P is up-to-date, at least if the
- [changelogs](https://geti2p.net/en/blog/) mention that
- security critical bugs were fixed.
-* Check that "Applications -> Internet -> I2P" works:
- - You get the "Starting I2P..." pop-up.
- - The router console opens in Iceweasel upon success.
- - You get the "I2P failed to start" pop-up on failure (e.g. no
- network so tordate failed).
-* Check that I2P connects to the network:
- - Go to <http://127.0.0.1:7657/i2ptunnelmgr>
- - You should get "Network: Hidden" in the "General" section.
- - The numbers in the "Peers" section of the sidebar should be non-zero.
-* Check that you can reach some eepsites within Iceweasel, like
- <http://i2p-projekt.i2p> and <http://forum.i2p>.
-* Check that you can connect to the I2P IRC server through Pidgin and
- the preconfigured IRC account on 127.0.0.1.
+Make sure that I2P is up-to-date, at least if the
+[changelogs](https://geti2p.net/en/blog/) mention that
+security critical bugs were fixed.
+
+Start I2P by appending `i2p` to the kernel command line.
+
+* Check that I2P starts when a network interface is up:
+ - Within 30 seconds you should get the "I2P router console is ready"
+ pop-up
+ - Start the I2P Browser via "Applications -> Internet -> I2P Browser":
+ * You get the "Starting I2P Browser..." pop-up.
+ * The router console (<http://127.0.0.1:7657>) opens successfully
+ upon success.
+ * On exiting I2P Browser, check that its chroot gets properly torn
+ down on exit (there should be nothing mounted inside
+ `/var/lib/i2p-browser`).
+ - After a few minutes you should get the "I2P is ready" pop-up
+ - Go to <http://127.0.0.1:7657/i2ptunnelmgr> in the I2P Browser:
+ * You should get "Network: Hidden" in the "General" section.
+ * The numbers in the "Peers" section of the sidebar should be
+ non-zero.
+ * Check that you can reach some eepsites within Iceweasel, like
+ <http://i2p-projekt.i2p> and <http://forum.i2p>.
+ - Check that you can connect to the I2P IRC server through Pidgin
+ and the preconfigured IRC account on 127.0.0.1.
+* Check I2P failure modes:
+ - Router console failure:
+ * Boot without network so I2P doesn't start automatically.
+ * Block the router console port: `nc -l -p 7657 -t 127.0.0.1`
+ * Plug the network
+ * You should get the "I2P failed to start" pop-up, and I2P should
+ not be running (check with `service i2p status`)
+ - Bootstrap failure:
+ * Detach the network immediately after getting the "I2P router
+ console is ready" pop-up
+ * Wait for up to six minutes
+ * You should get the "I2P is not ready" pop-up
+ * The I2P router console should still be accessible on
+ <http://127.0.0.1:7657>
# Git
* clone a repository over `git://`
+
+ git clone git://git.tails.boum.org/htp
+
* clone a repository over `https://`
+
+ git clone https://git-tails.immerda.ch/htp
+
* clone a repository over SSH
# SSH
@@ -464,14 +504,14 @@ correctly.
Else, use a local test setup:
* A web server on the LAN.
- * A copy of `wiki/src/update` from the `stable` or `testing` branch,
- for example in `/var/www/tails/update/v1/Tails/0.14~rc2/i386/stable/updates.yml`
+ * A copy of `wiki/src/upgrade` from the `stable` or `testing` branch,
+ for example in `/var/www/tails/upgrade/v1/Tails/0.14~rc2/i386/stable/updates.yml`
* A copy of the `iuk` directory of our HTTP mirrors,
for example in `/var/www/tails/stable/iuk/Tails_i386_0.14-rc2_to_0.14.iuk`.
To synchronize your local copy:
- torsocks rsync -rt --progress rsync.torproject.org::amnesia-archive/tails/stable/iuk/ /var/www/tails/stable/iuk/
+ torsocks rsync -rt --progress --delete rsync.torproject.org::amnesia-archive/tails/stable/iuk/ /var/www/tails/stable/iuk/
* Patch `/etc/hosts` in Tails to point to your web server:
@@ -497,18 +537,20 @@ correctly.
Enable Windows camouflage via the Tails Greeter checkbox and:
* Tails OpenPGP Applet's context menu should look readable
-* iceweasel should use a Internet Explorer theme
+* 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:
- - it has no scary red theme when Windows Camouflage is activated.
- - the iceweasel instance runs as the `clearnet` user.
+ - the Tor Browser instance runs as the `clearnet` user.
- it has no proxy configured.
- no extensions are installed.
- - there are no bookmarks.
+ - 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`).
@@ -535,15 +577,15 @@ Enable Windows camouflage via the Tails Greeter checkbox and:
# Internationalization
Boot and check basic functionality is working for every supported
-language.
+language. You *really* have to reboot between each language.
* The chosen keyboard layout must be applied.
* The virtual keyboard must work and be auto-configured to use the same keyboard
layout as the X session.
* The Startpage search engine must be localized for the languages we ship a
- searchplug for:
+ search plugin for:
- find /usr/share/amnesia/iceweasel/searchplugins/locale/ -iname startpage-*.xml
+ find /usr/local/lib/tor-browser/distribution/searchplugins/locale -iname startpage-*.xml
* The Wikipedia search engine must be localized for all languages.
diff --git a/wiki/src/contribute/release_process/test/automated_tests.mdwn b/wiki/src/contribute/release_process/test/automated_tests.mdwn
index 3ee785c..22db600 100644
--- a/wiki/src/contribute/release_process/test/automated_tests.mdwn
+++ b/wiki/src/contribute/release_process/test/automated_tests.mdwn
@@ -1,3 +1,5 @@
+[[!meta title="Automated test suite"]]
+
[[!toc levels=2]]
# Introduction
diff --git a/wiki/src/contribute/release_process/test/erase_memory_on_shutdown.mdwn b/wiki/src/contribute/release_process/test/erase_memory_on_shutdown.mdwn
index 5b25a31..0a27803 100644
--- a/wiki/src/contribute/release_process/test/erase_memory_on_shutdown.mdwn
+++ b/wiki/src/contribute/release_process/test/erase_memory_on_shutdown.mdwn
@@ -35,12 +35,10 @@ Pick one of those:
# 2. Test that you can get the pattern after rebooting, if no memory wiping takes place
* Make sure your preferred memory scrapper toolkit is ready.
-* Reboot from Tails using `SysRq + b`; if testing in a VM, you'd
- better be careful not rebooting your host system and proceed like
- this:
-
- echo 1 > /proc/sys/kernel/sysrq ; echo b > /proc/sysrq-trigger
-
+* Kill fillram processes and reboot with `SysRq + 1` when free memory is under a threshold by running:
+
+ while [ $(free -m -o | grep Mem | sed -e 's/ */ /g' | cut -d ' ' -f 4) -ge 256 ] ; do sleep 0.1 ; done ; killall fillram ; echo 1 > /proc/sys/kernel/sysrq ; echo b > /proc/sysrq-trigger
+
* Dump memory and try to find the known pattern in it, e.g.:
grep -c wipe_didnt_work tails.dump
@@ -57,7 +55,7 @@ Pick one of those:
command-line if your memory scrapper toolkit needs it).
* Kill fillram processes and reboot Tails when free memory is under a threshold by running:
- while [ $(free -m -o | grep Mem | sed -e 's/ */ /g' | cut -d ' ' -f 4) -ge 128 ] ; do sleep 0.1 ; done ; killall fillram ; reboot
+ while [ $(free -m -o | grep Mem | sed -e 's/ */ /g' | cut -d ' ' -f 4) -ge 256 ] ; do sleep 0.1 ; done ; killall fillram ; reboot
This is especially important on 486 kernels. The threshold might be fine tuned.
diff --git a/wiki/src/contribute/release_process/test/erase_memory_on_shutdown/qemu_pmemsave.mdwn b/wiki/src/contribute/release_process/test/erase_memory_on_shutdown/qemu_pmemsave.mdwn
index 79bc765..eea80ed 100644
--- a/wiki/src/contribute/release_process/test/erase_memory_on_shutdown/qemu_pmemsave.mdwn
+++ b/wiki/src/contribute/release_process/test/erase_memory_on_shutdown/qemu_pmemsave.mdwn
@@ -4,11 +4,11 @@ Note that you need the qemu command, which is provided on wheezy by the `qemu-sy
- with a 64-bit CPU that supports PAE
- qemu -enable-kvm -cpu Nehalem -cdrom tails.iso -m 5120 -no-reboot -no-shutdown
+ qemu -enable-kvm -cpu Nehalem -cdrom tails.iso -m 5120
- with a 32-bit CPU that does not support PAE
- qemu -enable-kvm -cpu 486 -cdrom tails.iso -m 5120 -no-reboot -no-shutdown
+ qemu -enable-kvm -cpu 486 -cdrom tails.iso -m 5120
* Open the qemu console (CTRL-ALT-2).
* Save physical memory to the `tails.dump` file (length is an integer, max size for one dump is 4G = 0xF0000000):
diff --git a/wiki/src/contribute/release_process/test/setup.mdwn b/wiki/src/contribute/release_process/test/setup.mdwn
index 52cfe63..d9b35d4 100644
--- a/wiki/src/contribute/release_process/test/setup.mdwn
+++ b/wiki/src/contribute/release_process/test/setup.mdwn
@@ -13,11 +13,18 @@ Install dependencies
The following packages are necessary on Debian Wheezy, with
wheezy-backports sources added:
+ echo 'deb http://ftp.us.debian.org/debian/ testing main contrib non-free' \
+ > /etc/apt/sources.list.d/testing.list && \
+ echo -e "Package: *\nPin: release o=Debian,a=stable\nPin-Priority: 990" \
+ > /etc/apt/preferences.d/Debian_stable && \
+ 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 \
libxslt1-dev tcpdump unclutter radvd x11-apps syslinux \
- libcap2-bin devscripts libvirt-ruby ruby-rspec gawk ntp \
- ruby-json x11vnc xtightvncviewer ffmpeg libvpx1 dnsmasq-base \
- openjdk-7-jre && \
+ 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 && \
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
@@ -25,10 +32,19 @@ wheezy-backports sources added:
Other requirements
==================
+Synchronized clock
+------------------
+
The system running the test suite needs an accurate clock since we
sync the clock from the host to the Tails guest after a background
snapshot restore to appease Tor. This is why we installed ntp above.
+File permissions
+----------------
+
+The user that runs QEMU (via libvirt) needs read-access at least to
+the content of `features/misc_files/` in the Git checkout.
+
Special use cases
=================
@@ -46,6 +62,10 @@ where `$DISPLAY` is the display given to you by `run_test_suite` (often 0):
Running the test suite as a non-root user
-----------------------------------------
+<div class="note">
+This section may not be in tested and working shape.
+</div>
+
This is entirely possible, but there's some additional configuration
required. Run the following as `root`:
diff --git a/wiki/src/contribute/release_process/test/usage.mdwn b/wiki/src/contribute/release_process/test/usage.mdwn
index 14b3892..1535360 100644
--- a/wiki/src/contribute/release_process/test/usage.mdwn
+++ b/wiki/src/contribute/release_process/test/usage.mdwn
@@ -17,7 +17,7 @@ A typical example run of a few `@product` features could be:
--iso path/to/tails.iso \
features/apt.feature features/erase_memory.feature
-which will test only the `iceweasel` and `erase_memory` features (if
+which will test only the `apt` and `erase_memory` features (if
no feature paths are given, all features in `features/cucumber` will
be tested) of the given ISO image `tails.iso` while showing the test
session in a VNC viewer (`--view`) and also capturing it into a video
diff --git a/wiki/src/contribute/release_process/tor-browser.mdwn b/wiki/src/contribute/release_process/tor-browser.mdwn
new file mode 100644
index 0000000..3a02d1d
--- /dev/null
+++ b/wiki/src/contribute/release_process/tor-browser.mdwn
@@ -0,0 +1,43 @@
+[[!meta title="Releasing the Tor Browser"]]
+
+Have a look at
+
+* <https://archive.torproject.org/tor-package-archive/torbrowser/>
+* <https://www.torproject.org/dist/torbrowser/>
+* <https://people.torproject.org/~mikeperry/builds/>
+* <https://people.torproject.org/~linus/builds/>
+
+and see if the desired version is available. We prefer
+`archive.torproject.org` 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:
+
+ DIST_URL=https://people.torproject.org/~mikeperry/builds/
+ VERSION=4.0
+
+Fetch the version's `sha256sums.txt` and `sha256sums.txt.asc` and
+verify with `gpg`:
+
+ wget ${DIST_URL}/${VERSION}/sha256sums.txt{,.asc} && \
+ gpg --verify sha256sums.txt.asc
+
+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 > \
+ config/chroot_local-includes/usr/share/tails/tbb-sha256sums.txt
+
+Then update the url to the one chosen above:
+
+ echo "${DIST_URL}" | sed "s,^https://,http://," > \
+ config/chroot_local-includes/usr/share/tails/tbb-dist-url.txt
+
+NOTE: We must use http (not http**s**) due to limitations/bugs in
+`apt-cacher-ng`, 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}."