Read this document from the branch used to prepare the release.


Keeping an eye on the changes between released versions is one of the many safeguards against releasing crap.


Compare the to-be-released source code with previous version's one e.g.:

Boot the candidate image and find the commit it was build from with the tails-version command.

Then, from the source tree, see the diff:

git diff --find-renames <old image commit>..<candidate image commit>

e.g. git diff --find-renames 334e1c485a3a79be9fff899d4dc9d2db89cdc9e1..cfbde80925fdd0af008f10bc90c8a91a578c58e3


Compare the list of bundled packages and versions with the one shipped last time. .packages are usually attached to the email announcing the image is ready.

/usr/bin/diff -u \
    wiki/src/torrents/files/tails-amd64-3.1.packages \
    tails-amd64-3.2.packages \
    | wdiff --diff-input  --terminal

Check the output for:

  • new packages that may cause harm or make the images unnecessarily big
  • packages that could be erroneously removed
  • new versions of software we might not have audited yet (including: does the combination of our configuration with software X version Y+1 achieve the same wished results as with software X version Y?)

Image size

Check the images size has not changed much since the last release.

In a directory with many Tails ISO and USB images:

find \( -iname "tails*.iso" -o -iname "tails*.img" \) \
     -type f -exec ls -l --block-size=M '{}' \; | sort -rhk 5


This section can not be done by the RM.

  1. Download the ISO and USB images.

  2. Clear-sign the hashes of all products using your OpenPGP key and gzip the output (otherwise the signed text could be mangled at some point in the email chain):

     DEST_DIR=$(mktemp -d)
     sha512sum *.iso *.img \
       | gpg --clear-sign \
       | gzip \
       > "$DEST_DIR/TR-bits.gz"
  3. Locate the file generated by the command above. To display its location, execute the following command:

     echo "$DEST_DIR/TR-bits.gz"
  4. Send the aforementioned generated file as an attachment to the Trusted Reproducer, whose name is on the release calendar.

  5. If the Trusted Reproducer is around, ask them:

    • if they've received your email
    • if they could successfully decompress the attachment
    • if they could check the inline signature of the attachment once decompressed
    • if the signed text contains all the information they need

Automated test suite

Our long term goal is to eliminate the manual test suite (except the parts which require real hardware) and have the automated test suite run all our tests. Its design, and how to write new tests, are documented on a dedicated page.

Running the automated test suite

See setup and usage.

Do point --old-iso to the ISO image of the previous stable release.

Automated test suite migration progress

The manual test suite below either contains tests that cannot be automated, has no automated test implemented yet, or has a test 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:.

Tor Browser

Miscellaneous functionality

  • Test if uBlock works:
    • The uBlock icon must be visible.
    • Visit a website that normally displays ads, such as The ads should not be displayed and the uBlock icon should display a strictly positive number of blocked elements.

Security and fingerprinting

  • Run the tests the Tor Browser folks use and compare to the last released version of Tails. Results should not be worse. (automate: #10260)
    • For the "evercookie" test to work, you may have to disable uBlock on its web page.
  • Download the same version of Tor Browser and compare its fingerprint (running on Linux outside of Tails) with Tor Browser in Tails, using at least (automate: #10262). Click "Show full results for fingerprinting" to see the details we're interested in.
    • The exposed User-Agent should match the latest Tor Browser's one.
    • Ignore the result of the "blocking tracking ads" and "blocking invisible trackers" tests, which seem unreliable (we've seen different results for the very same version of Tor Browser).
    • Update the Browser fingerprint section of the known issues if needed.
  • WebRTC should be disabled: (automate: #10264)
    • In about:config check that media.peerconnection.enabled is set to false.
    •, especially the getUserMedia test. It's expected that the audio test works if you agree to share a microphone with the remote website; anything else should fail.
    • should display literally ifconfig | grep inet | grep -v inet6 | cut -d" " -f2 | tail -n1


Onion services

To test that Onion service support works:

  1. Configure an IMAP email account using auto-discovered (non-Onion) server settings using a provide that also provides onion services for IMAP, POP, and SMTP: for example,
  2. In Preferences → Account Settings → Server Settings, switch the Server Name to the email provider's onion service (e.g. Riseup, 5gdvpfoh6kb2iqbizb37lzk2ddzrwa47m6rpdueg2m656fovmbhoptqd.onion on port 993 with SSL).
  3. In Preferences → Account Settings → Outgoing Server (SMTP), switch the Server Name to the email provider's onion service (see above, on port 465 with SSL).
  4. Check email over IMAP.
  5. Send an email and verify it's received.
  6. Repeat the process with POP (see above, on port 995 with SSL) instead of IMAP.


To check that the EHLO/HELO SMTP message is not leaking anything at the application level:

  1. Start Thunderbird using the GNOME Applications menu.
  2. Configure the outgoing SMTP server for an email account so it uses STARTTLS on port 587 (Thunderbird will send two EHLO/HELO: one before TLS is initiated; one after; the assumption here is that Thunderbird will send the same both times).
  3. Run sudo tcpdump -n -i lo -w dump while sending an email to capture the packets before Tor encrypts it, then close tcpdump. Note that the packet containing EHLO/HELO will be sent really early, so even if the email failed (e.g. because the mail server doesn't support plaintext SMTP on port 587) we are ok.
  4. Check the dump for the HELO/EHLO message and verify that it only contains sudo tcpdump -A -r dump | grep EHLO



  • I should be able to send a bug report with WhisperBack.
  • When we receive this bug report on the tails-bugs mailing list, Schleuder tells us that it was sent encrypted.

Root access control

  1. Start the candidate Tails image.
  2. Do not set an administration password.
  3. Check you cannot login as root with /bin/su neither with the amnesia password nor with the live one. (automate: #10274)

Virtualization support

  • Test that Tails starts and the browser launches in VirtualBox.

APT (automate: #17017)

 grep -r jenw7xbd6tf7vfhp.onion /etc/apt/sources.list*
  • Make sure the Tails repository suite in matching the release tag (for example the release version number) is in APT sources.
  • Make sure the Tails repository unversioned suites (e.g. testing, stable and devel) are not in APT sources.

Incremental upgrades

  1. Install from scratch on a USB stick the previous Tails stable release (that is, at this time, the current published one). A system that was upgraded to that version will not do.

  2. Start from that USB stick.

  3. Set an administration password in the Welcome Screen.

  4. Upgrade to the version we're testing:

     sudo sh -c 'sed -i /^TAILS_CHANNEL=/d /etc/os-release &&
                 echo TAILS_CHANNEL=\"test\" >> /etc/os-release' && \
     systemctl --user restart tails-upgrade-frontend.service
  5. Once the upgrade has been applied and you're suggested to restart Tails, do that.

  6. Verify that the resulting, upgraded system "works fine":

    • it boots
    • it pretends to be the correct version
    • Tor works fine
    • Tor Browser works fine
    • the Unsafe Browser starts

Tails Verification

  • The goal is to check that Tails Verification works in Tor Browser in the version of Tails we are testing here. Tails Verification only supports verifying the current release so for example, when doing tests for the Tails 3.13 release, we use it in the tentative Tails 3.13 to verify the Tails 3.12 ISO and USB images.

    1. Start the Tails that you are testing.

    2. Start Tor Browser.

    3. Visit

    4. If you already have the ISO image for the last, already released version of Tails, i.e. the one that's advertised in the sidebar of our production website, then click "I already downloaded Tails $N". Otherwise follow the instructions on that web page to download the ISO image.

    5. Install Tails Verification.

    6. Click the Verify Tails $N button.

    7. The verification should be successful.

    8. Repeat for the USB image, except the URL for step (3) is:


Make sure that the .torrent files we advertise for this release can be used to download the full images:

  • ISO

  • USB image

Real (non-VM) hardware


Note that for release candidates, we do not always optimize the ordering of files in the SquashFS, which might make them boot somewhat slower.

On a 64-bit computer that has Secure Boot enabled and that is configured to prefer UEFI:

  1. Freshly install the version of Tails being tested to a USB stick.
  2. Boot this USB stick on bare-metal a first time to trigger re-partitioning. You should the "GNU GRUB" title, as opposed to a syslinux menu.
  3. Boot this USB stick a second time, measuring the boot time (from the GRUB menu until the GNOME desktop is ready -- quickly press ENTER in the Welcome Screen).
  4. Compare with the boot time of the previous Tails version. The new one should not be significantly slower to start.

On a computer configured to prefer legacy BIOS boot:

  1. Freshly install the version of Tails being tested to a USB stick.
  2. Boot this USB stick on bare-metal a first time to trigger re-partitioning. You should see the "SYSLINUX" title in the bootloader, as opposed to GRUB.
  3. Boot this USB stick a second time.
  4. You should see the Welcome Screen appear.


  • The "Tails documentation" desktop launcher should open the doc page (automate: #8788):
    • in one language to which the website is translated
    • in one language to which the website is not translated: this should open the page in English
  • Browse around in the documentation shipped in the image and check that internal links work fine (automate: #10254):



Tier-1 languages

Boot and check basic functionality is working for our best supported (Tier-1) languages.

You really have to reboot between each language.

  • The chosen keyboard layout must be applied. (automate: #10261) This is known to be broken in some languages, such as Arabic: #12638.
  • The screen keyboard must (automate: #10263):
    • work in Tor Browser when activated after the browser has started;
    • work in Thunderbird when activated after Thunderbird has started;
    • be auto-configured to use the same keyboard layout as the X session (known exceptions: Chinese, Persian, Português, Russian, Tiếng Việt).
  • In the Tor Browser:
    • DuckDuckGo must be the default, pre-selected search plugin. (automate: #10265)


To see which among the supported locales there should be a spellchecker, run this in a Tails Git checkout of the commit the release under testing was built from:

git grep -E '^hunspell' config/chroot_local-packageslists/tails-common.list

Then do the follow in the same Tor Browser session running in the en_US.UTF-8 locale (or whatever locale you are most comfortable identifying other language names in):

  • Check that the expected languages are listed in the list of languages for spell checking. (automate: #10269)
  • For a few languages, check the spell checking:
    • Type something in the textarea.
    • Right-click and select a language.
    • Verify that the spelling suggestion are from that language. (automate: #10271)


  • Check that all seems well during init: (automate: #10277)
    • systemctl --failed --all should either say 0 loaded units listed, or list rng-tools.service as the only unit in failed state.
    • the output of sudo journalctl should seem OK. For a quick overview, something like sudo journalctl -p 0..3 can be helpful.