summaryrefslogtreecommitdiffstats
path: root/wiki/src/contribute
diff options
context:
space:
mode:
Diffstat (limited to 'wiki/src/contribute')
-rw-r--r--wiki/src/contribute/APT_repository/time-based_snapshots.mdwn2
-rw-r--r--wiki/src/contribute/build.mdwn5
-rw-r--r--wiki/src/contribute/calendar.mdwn19
-rw-r--r--wiki/src/contribute/design.mdwn31
-rw-r--r--wiki/src/contribute/git.mdwn103
-rw-r--r--wiki/src/contribute/how/documentation/guidelines.mdwn8
-rw-r--r--wiki/src/contribute/how/documentation/release_notes.mdwn31
-rw-r--r--wiki/src/contribute/how/documentation/release_notes/template.mdwn4
-rw-r--r--wiki/src/contribute/how/promote.mdwn3
-rw-r--r--wiki/src/contribute/meetings/201310.mdwn16
-rw-r--r--wiki/src/contribute/meetings/201403.mdwn4
-rw-r--r--wiki/src/contribute/meetings/201408.mdwn2
-rw-r--r--wiki/src/contribute/meetings/201501.mdwn4
-rw-r--r--wiki/src/contribute/meetings/201611.mdwn33
-rw-r--r--wiki/src/contribute/meetings/201612.mdwn64
-rw-r--r--wiki/src/contribute/meetings/201701.mdwn42
-rw-r--r--wiki/src/contribute/release_process.mdwn404
-rw-r--r--wiki/src/contribute/release_process/icedove.mdwn28
-rw-r--r--wiki/src/contribute/release_process/tails-installer.mdwn23
-rw-r--r--wiki/src/contribute/release_process/test.mdwn17
-rw-r--r--wiki/src/contribute/release_process/test/automated_tests.mdwn19
-rw-r--r--wiki/src/contribute/release_process/test/usage.mdwn17
-rw-r--r--wiki/src/contribute/release_process/tor-browser.mdwn8
-rw-r--r--wiki/src/contribute/working_together/roles/test_suite.mdwn9
24 files changed, 608 insertions, 288 deletions
diff --git a/wiki/src/contribute/APT_repository/time-based_snapshots.mdwn b/wiki/src/contribute/APT_repository/time-based_snapshots.mdwn
index 5e96a44..3aef34f 100644
--- a/wiki/src/contribute/APT_repository/time-based_snapshots.mdwn
+++ b/wiki/src/contribute/APT_repository/time-based_snapshots.mdwn
@@ -221,7 +221,7 @@ a distribution, keeping references to the packages it contains.
Compared to the "snapshots as full-blown distributions + `reprepro
pull`" option we
-[used in our initial experiments](https://labs.riseup.net/code/issues/6295#note-14),
+[[!tails_ticket 6295#note-14 desc="used in our initial experiments"]],
we are saving _a lot_ on database size, and thus in performance,
because reprepro does less tracking on snapshots, than what it does
for real distributions.
diff --git a/wiki/src/contribute/build.mdwn b/wiki/src/contribute/build.mdwn
index f0f99eb..9521e16 100644
--- a/wiki/src/contribute/build.mdwn
+++ b/wiki/src/contribute/build.mdwn
@@ -244,10 +244,9 @@ uncommitted changes. This behaviour can be controlled by:
The fastest build you could pretend to get can be done by setting:
- export TAILS_BUILD_OPTIONS="ram cache extproxy gzipcomp"
+ export TAILS_BUILD_OPTIONS="ram extproxy gzipcomp"
-This will force the build to happen in RAM and allow skipping the
-boostrap stage if one is cached, and will use use an HTTP proxy
+This will force the build to happen in RAM, and will use use an HTTP proxy
external to the virtual machine, and SquashFS compression will be done
using *gzip*.
diff --git a/wiki/src/contribute/calendar.mdwn b/wiki/src/contribute/calendar.mdwn
index f05cf29..9d7a189 100644
--- a/wiki/src/contribute/calendar.mdwn
+++ b/wiki/src/contribute/calendar.mdwn
@@ -1,7 +1,20 @@
[[!meta title="Calendar"]]
-* 2016-12-13: Release 2.9 (Firefox 45.6) - anonym is the RM
+* 2017-03-07: Release 2.11 (Firefox 45.8, 52.0) - bertagaz is the RM
-* 2017-01-24: Release 2.10 (Firefox 45.7) - anonym is the RM
+* 2017-04-18: Release 2.12 (Firefox 45.9, 52.1) - anonym is the RM
-* 2017-03-07: Release 2.11 (Firefox 45.8) - bertagaz is the RM
+* 2017-06-13: Release 3.0? (Firefox 52.2) - intrigeri is the RM
+
+* 2017-08-08: Release 3.1? (Firefox 52.3)
+ - bertagaz is the RM?
+ - intrigeri is on-call for foundations work (fix 3.0 bugs) until
+ 2017-07-20.
+ - anonym would like to be more or less AFK during the whole cycle.
+ Possibly he takes over intrigeri's hat after 2017-07-20.
+
+* 2017-10-03: Release 3.2? (Firefox 52.4) - anonym is the RM
+
+* 2017-11-28: Release 3.3? (Firefox 52.5) - anonym is the RM
+
+* 2018-01-22: Release 3.4? (Firefox 52.6)
diff --git a/wiki/src/contribute/design.mdwn b/wiki/src/contribute/design.mdwn
index db7ebe4..4bb9674 100644
--- a/wiki/src/contribute/design.mdwn
+++ b/wiki/src/contribute/design.mdwn
@@ -822,10 +822,10 @@ those are mainly for usability issues and similar.
### 3.6.1 The Tor™ software
The Tor software is currently configured as a client only (onion
-proxy). The client listens on a control port 9051
-(using cookie authentication), as a transparent proxy on port 9040
-(only used for remapped hidden services) and as a DNS server on port
-8853.
+proxy). The client listens for control connections on port 9052 (using
+cookie authentication) which is non-standard (see about the "control
+port filter" below), as a transparent proxy on port 9040 (only used
+for remapped hidden services) and as a DNS server on port 8853.
The client listens on a few SOCKS ports (the rationale being detailed
on the [[Tor stream isolation design
@@ -841,11 +841,17 @@ If a compromised software had access to the Tor control port,
an attacker who controls it could simply ask Tor the public
IP through the `GETINFO address` command.
To prevent this, access to the Tor control port is only
-granted to the `root` and `tor-launcher` users, as well as to the
-members of the `debian-tor` group, such as the `onioncircuits` user
-(that is used to run Onion Circuits).
-A filtering proxy to the control port exists, so
-Torbutton still can perform safe commands like `SIGNAL NEWNYM`.
+granted to the `root` user, as well as to the
+members of the `debian-tor` group (via the control socket).
+A filtering proxy to the control port runs on port 9051 (i.e. the default
+Tor ControlPort), so for instance
+Torbutton still can perform safe commands like `SIGNAL NEWNYM`. It
+allows defining fine-grained access whitelists of commands (and their
+argunents) and events on a per-application basis, which can enforce
+rules like "this `$user` (e.g. `amnesia`) when running this
+`$application` (e.g. `/usr/bin/onionshare`) can only run these commands
+(`ADD_ONION` etc.) and listen to these events (e.g. `HS_DESC`, which is
+expected after a successfull use of `ADD_ONION`)".
We disabled the default warning messages of Tor (`WarnPlaintextPorts`)
when connecting to ports 110 (POP3) and 143 (IMAP). These ports are used
@@ -854,7 +860,7 @@ providers recommend and even enforce StartTLS on these ports, the effect
of these warnings were most of the time counterproductive as people had
to click through needlessly scary security warnings.
-- [[!tails_gitweb config/chroot_local-hooks/06-adduser_onioncircuits]]
+- [[!tails_gitweb_dir config/chroot_local-includes/etc/tor-controlport-filter.d/]]
- [[!tails_gitweb config/chroot_local-includes/lib/systemd/system/tor-controlport-filter.service]]
- [[!tails_gitweb config/chroot_local-includes/usr/local/lib/tor-controlport-filter]]
- [[!tails_gitweb config/chroot_local-includes/etc/tor/torrc]]
@@ -865,7 +871,6 @@ Status extension provides a permanent visual indication of whether Tor
has bootstrapped already.
- [[!tails_gitweb_dir config/chroot_local-includes/usr/share/gnome-shell/extensions/torstatus@tails.boum.org/extension.js]]
-- [[!tails_gitweb config/chroot_local-includes/usr/local/bin/onioncircuits]]
<a id="dns"></a>
@@ -978,7 +983,7 @@ The default profile is split from the binaries and application data:
As for extensions we have the following differences:
* Tails also installs the
- [Adblock plus](https://addons.mozilla.org/fr/firefox/addon/1865/)
+ [uBlock Origin](https://github.com/gorhill/uBlock/)
extension to protect against many tracking possibilities by removing
most ads.
@@ -1418,7 +1423,7 @@ issues|support/known_issues]] page.
However the fact that different browser extensions are installed in Tails and in
the TBB surely allows more sophisticated attacks that usual fingerprint
as returned by tools such as <https://panopticlick.eff.org/> and
-<http://ip-check.info/>. For example, the fact that Adblock is removing
+<http://ip-check.info/>. For example, the fact that uBlock Origin is removing
ads could be analysed.
From the point of view of the local network administrator, Tails is
diff --git a/wiki/src/contribute/git.mdwn b/wiki/src/contribute/git.mdwn
index 7cc1978..b1f5eda 100644
--- a/wiki/src/contribute/git.mdwn
+++ b/wiki/src/contribute/git.mdwn
@@ -41,6 +41,8 @@ Here are a couple of links to get started with Git:
General information
===================
+<a id="immerda"></a>
+
Git hosting setup at immerda
----------------------------
@@ -62,11 +64,6 @@ the development team signing key the default one for Git tags:
git config user.signingkey A490D0F4D311A4153E2BB7CADBB802B258ACD84F
-Creating a new repository
--------------------------
-
-Create a new repository at immerda.
-
Repositories
============
@@ -180,6 +177,8 @@ merged before being renamed, and our Jenkins instance will not build nor
test it, so you won't get notifications for a branch that you know is
breaking the build and/or the test suite.
+<a id="promotion-material"></a>
+
Promotion material
------------------
@@ -282,3 +281,97 @@ For more information, see:
in the *Pro Git* book;
* the [`git-submodule(1)`](http://manpages.debian.org/git-submodule)
man page.
+
+<a id="creating-a-new-repository"></a>
+
+Creating a new repository
+=========================
+
+In the vast majority of cases, your new repository will be hosted
+at <https://git-tails.immerda.ch/>. Here is how to get it created.
+
+1. Send your OpenPGP public key, pasted in the body of an email, to
+ the [[Tails system administrators|about/contact#tails-sysadmins]].
+ State that you want to establish a communication channel in order
+ to eventually get a Git repository created. Do not _attach_ your
+ public key, this would not work due to bugs in the mailing list
+ software we use.
+2. Wait for the Tails system administrators to confirm they have
+ received your OpenPGP public key and imported it into the keyring
+ of their mailing list.
+3. Send your Git repository request in an OpenPGP-signed email to the
+ [[Tails system administrators|about/contact#tails-sysadmins]];
+ include the following information:
+ - the name you want to publicly use in our Git repository hosting
+ system (only lower-case ASCII chars and digits);
+ - the preferred name of the repository you want to create
+ (only lower-case ASCII chars and digits);
+ - your SSH RSA public key;
+ - whether the repository shall be publicly available or not;
+ - who else needs read access to the repository, plus their SSH RSA
+ public key;
+ - who else needs write access to the repository, plus their SSH RSA
+ public key.
+
+Once your repository has been created, clone it:
+
+* If you want to encrypt the content of your new Git repository with
+ OpenPGP, go through some arcane
+ [[initialization ritual|contribute/git#initialize-git-remote-gcrypt]]
+ to reach wisdom, bliss and enlightenment.
+* Otherwise (lucky you!), see:
+ - [[addresses for Git clone and web access|contribute/git#other-repositories]]
+ - [[immerda's documentation|contribute/git#immerda]].
+
+<a id="initialize-git-remote-gcrypt"></a>
+
+Initializing a git-remote-gcrypt repository
+===========================================
+
+Clone the new, empty repository in a way that tells Git it's going to
+be encrypted:
+
+ git clone gcrypt::tails@git-tails.immerda.ch:$REPOSITORY
+
+Change directory into the newly cloned repository:
+
+ cd $REPOSITORY
+
+Decide whether you want to hide to the immerda administrators which
+OpenPGP keys this repository will be encrypted for (note that this has
+severe usability drawbacks). Skip to the next step if you really want
+that. Otherwise:
+
+ git config gcrypt.publish-participants true
+
+Tell Git which OpenPGP keys the repository will be encrypted for:
+
+ git config gcrypt.participants "LIST OF OPENPGP FINGERPRINTS"
+
+Write some setup instructions for your team-mates, e.g. copy and
+paste the `git config` command(s) you have just run:
+
+ editor README
+
+Add these setup instructions to the repository and commit:
+
+ git add README && git commit -m 'Add setup documentation.'
+
+Push:
+
+ git push -u origin master
+
+Troubleshooting
+===============
+
+First, check with your team-mates: in some cases they can help you
+troubleshoot your problem, and confirm whether the problem is on your
+side or on the server side. If that is not enough, read on.
+
+* For repositories hosted at `git-tails.immerda.ch` (aka.
+ `git.tails.boum.org`) or at `git.puppet.tails.boum.org`: get in
+ touch with
+ [[Tails system administrators|about/contact#tails-sysadmins]].
+
+* For repositories hosted at `webmasters.boum.org`: get in touch with
+ <root@boum.org>.
diff --git a/wiki/src/contribute/how/documentation/guidelines.mdwn b/wiki/src/contribute/how/documentation/guidelines.mdwn
index 63e3cfb..41133c7 100644
--- a/wiki/src/contribute/how/documentation/guidelines.mdwn
+++ b/wiki/src/contribute/how/documentation/guidelines.mdwn
@@ -116,10 +116,10 @@ is described in its principal use cases. For example:
<div class="bug">
-The screen reading functionality of <span class="application">GNOME
+<p>The screen reading functionality of <span class="application">GNOME
Orca</span> does not work neither with the <span
class="application">Tor Browser</span> nor with the <span
-class="application">Unsafe Web Browser</span>.
+class="application">Unsafe Web Browser</span>.</p>
</div>
@@ -131,9 +131,9 @@ be interesting to read next. For example:
<div class="next">
-You can also
+<p>You can also
[[decrypt or verify a text that is encrypted or signed using public-key cryptography|doc/encryption_and_privacy/gpgapplet/decrypt_verify]]
-using <span class="application">OpenPGP Applet</span>.
+using <span class="application">OpenPGP Applet</span>.</p>
</div>
diff --git a/wiki/src/contribute/how/documentation/release_notes.mdwn b/wiki/src/contribute/how/documentation/release_notes.mdwn
index 32ffe7d..4e56366 100644
--- a/wiki/src/contribute/how/documentation/release_notes.mdwn
+++ b/wiki/src/contribute/how/documentation/release_notes.mdwn
@@ -2,31 +2,38 @@
- Create a branch based on the development branch for this release
- `web/nnnnn-x.y-release-notes`
- - Copy template form contribute/how/documentation/release_notes/template.mdwn to news/version_x.y.mdwn
+ - Copy template from `contribute/how/documentation/release_notes/template.mdwn` to `news/version_x.y.mdwn`
+ - Replace placeholders in template
- Gather information about changes
- Tails changelog
- <https://git-tails.immerda.ch/tails/tree/debian/changelog?h=stable>
- - <https://git-tails.immerda.ch/tails/tree/debian/changelog?h=devel>
+ - <https://git-tails.immerda.ch/tails/tree/debian/changelog?h=testing>
- If a release candidate was announced, read the call for testing
- Analyze the changes already made on the website and link to them:
- - in testing for a major release: `git diff origin/master...origin/testing wiki/src`
- - in stable for a minor release: `git diff origin/master...origin/stable wiki/src`
+ - in testing for a major release: `git diff origin/master...origin/testing wiki/src/**/*.{mdwn,html}`
+ - in stable for a minor release: `git diff origin/master...origin/stable wiki/src/**/*.{mdwn,html}`
- Analyze the Redmine view for this release
- Analyze the diff of packages
- in testing for a major release: `wget http://nightly.tails.boum.org/build_Tails_ISO_testing/lastSuccessful/archive/latest.iso.packages`
- in stable for a minor release: `wget http://nightly.tails.boum.org/build_Tails_ISO_stable/lastSuccessful/archive/latest.iso.packages`
- `diff -u ~/Persistent/master/wiki/src/torrents/files/tails-i386-*.packages latest.iso.packages | wdiff --diff-input --terminal`
- Read the Changelog of other updated software (Tor, I2P, etc.) to find relevant highlights
- - <https://blog.torproject.org/>
- - <https://gitweb.torproject.org/tor.git/tree/ChangeLog>
- - <https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/Bundle-Data/Docs/ChangeLog.txt?h=maint-5.5>
- - <https://geti2p.net/en/>
- - <https://github.com/i2p/i2p.i2p/blob/master/debian/changelog>
- - <https://www.mozilla.org/en-US/thunderbird/notes/>
- - <https://github.com/spesmilo/electrum/blob/master/RELEASE-NOTES>
- - <https://gitweb.torproject.org/torbirdy.git/tree/ChangeLog>
+ - Tor: <https://blog.torproject.org/>
+ - Tor: <https://gitweb.torproject.org/tor.git/tree/ChangeLog>
+ - Tor Browser: <https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/Bundle-Data/Docs/ChangeLog.txt?h=maint-6.5>
+ - I2P: <https://geti2p.net/en/>
+ - I2P: <https://github.com/i2p/i2p.i2p/blob/master/debian/changelog>
+ - Icedove: <https://www.mozilla.org/en-US/thunderbird/notes/>
+ - Electrum: <https://github.com/spesmilo/electrum/blob/master/RELEASE-NOTES>
+ - TorBirdy: <https://gitweb.torproject.org/torbirdy.git/tree/ChangeLog>
+ - obfs4proxy: <https://anonscm.debian.org/cgit/pkg-privacy/packages/obfs4proxy.git/tree/ChangeLog>
- Add screenshots of cool stuff
- Resize them to 66% if needed
+ - Document manual steps that persistence users may need to go
+ through, taking into account that we support automatic updates
+ from the two last releases (not mentioning manual updates).
+ It may imply to refer to, or copy from, such instructions that
+ were documented in the _previous_ release notes.
- Write the draft
- Use full sentences for major changes ("*We installed*", "*You can*")
- Use present tense without subject for minor changes ("*Upgrade*", "*Fix*")
diff --git a/wiki/src/contribute/how/documentation/release_notes/template.mdwn b/wiki/src/contribute/how/documentation/release_notes/template.mdwn
index c273fb7..4826160 100644
--- a/wiki/src/contribute/how/documentation/release_notes/template.mdwn
+++ b/wiki/src/contribute/how/documentation/release_notes/template.mdwn
@@ -28,7 +28,9 @@ See the list of [[long-standing issues|support/known_issues]].
- To install, follow our [[installation instructions|install]].
-- To upgrade, an automatic upgrade is available from $VERSION-1 to $VERSION.
+- To upgrade, an automatic upgrade is available from $VERSION-2 and $VERSION-1 to $VERSION.
+
+ XXX: Check which IUK will be available with `git grep -l "to_${VERSION}\.iuk"` wiki/src/upgrade/v1/Tails/
If you cannot do an automatic upgrade or if you fail to start after an
automatic upgrade, please try to do a [[manual upgrade|upgrade]].
diff --git a/wiki/src/contribute/how/promote.mdwn b/wiki/src/contribute/how/promote.mdwn
index 5fa078d..864102e 100644
--- a/wiki/src/contribute/how/promote.mdwn
+++ b/wiki/src/contribute/how/promote.mdwn
@@ -48,6 +48,9 @@ Some minimal amount of [[advertising material|promote/material]] is available al
As you can see, there is room for improvement. Do not hesitate adding
to the list!
+This material lives in
+a [[dedicated Git repository|contribute/git#promotion-material]].
+
# Talk to us
You can subscribe to [[tails-project@boum.org|about/contact#tails-dev]],
diff --git a/wiki/src/contribute/meetings/201310.mdwn b/wiki/src/contribute/meetings/201310.mdwn
index f96fad7..b756089 100644
--- a/wiki/src/contribute/meetings/201310.mdwn
+++ b/wiki/src/contribute/meetings/201310.mdwn
@@ -4,11 +4,11 @@ Agenda
======
1. Decide if we care about the Pidgin CTCP replies
- https://labs.riseup.net/code/issues/6283
+ [[!tails_ticket 6283]]
2. Decide on throw keyids
- https://labs.riseup.net/code/issues/6152
+ [[!tails_ticket 6152]]
3. Test suite: retry when tor fails
- https://labs.riseup.net/code/issues/5770
+ [[!tails_ticket 5770]]
4. Broken window week
5. Monthly low-hanging fruits meeting?
@@ -17,8 +17,8 @@ Decide if we care about the Pidgin CTCP replies
### Introduction
-* https://labs.riseup.net/code/issues/6283
-* Parent ticket https://labs.riseup.net/code/issues/5823
+* [[!tails_ticket 6283]]
+* Parent ticket [[!tails_ticket 5823]]
Pidgin responds to PING returning a time duration and VERSION returning
'Purple IRC'.
@@ -34,8 +34,8 @@ Decide on throw keyids
### Introduction
-* https://labs.riseup.net/code/issues/6152
-* Parent ticket https://labs.riseup.net/code/issues/6153
+* [[!tails_ticket 6152]]
+* Parent ticket [[!tails_ticket 6153]]
--throw-keyids is a GnuPG option that hides the receiver of the encrypted
data as a countermeasure against traffic analysis.
@@ -56,7 +56,7 @@ Test suite: retry when tor fails
### Introduction
-https://labs.riseup.net/code/issues/5770
+[[!tails_ticket 5770]]
Some scenarios uses the live Tor network, which is not entirely reliable,
so we may get failing scenarios when in fact we just happened to pick a
diff --git a/wiki/src/contribute/meetings/201403.mdwn b/wiki/src/contribute/meetings/201403.mdwn
index 4ba36fb..e25d91c 100644
--- a/wiki/src/contribute/meetings/201403.mdwn
+++ b/wiki/src/contribute/meetings/201403.mdwn
@@ -3,7 +3,7 @@
6245: MD5 Reborned Hasher is incompatible with Firefox 20
---------------------------------------------------------
-<https://labs.riseup.net/code/issues/6245>
+[[!tails_ticket 6245]]
This ticket should be in Wait state instead of Discuss state. Another ticket has
been created as parent of this one:
@@ -15,7 +15,7 @@ been created as parent of this one:
6679: Do not auto-connect to the #tor IRC channel
-------------------------------------------------
-<https://labs.riseup.net/code/issues/6679>
+[[!tails_ticket 6679]]
This ticket has been renamed "Remove the preconfigured #tor IRC channel": we
don't auto-join the #tor channel, so the only way to have less people from Tails
diff --git a/wiki/src/contribute/meetings/201408.mdwn b/wiki/src/contribute/meetings/201408.mdwn
index ace0e78..c219eba 100644
--- a/wiki/src/contribute/meetings/201408.mdwn
+++ b/wiki/src/contribute/meetings/201408.mdwn
@@ -68,7 +68,7 @@ Press enquiries
=======================================================================================================================
- Three people (sajolida, jvoisin, and intrigeri) were convinced by anonym's
- [comment #2](https://labs.riseup.net/code/issues/7380#note-2) and agreed
+ [[!tails_ticket 7380#note-2 desc="comment 2"]] and agreed
with rejecting.
- Furthermore as anonym said, we might not want to change how Tails behaves
when opting-out of MAC spoofing, so it would turn the MAC option into a
diff --git a/wiki/src/contribute/meetings/201501.mdwn b/wiki/src/contribute/meetings/201501.mdwn
index f1cd79d..451409b9 100644
--- a/wiki/src/contribute/meetings/201501.mdwn
+++ b/wiki/src/contribute/meetings/201501.mdwn
@@ -26,12 +26,12 @@
# [[!tails_ticket 8447 desc="Persistent data is not erased when persistence features are disabled"]]
- - We acknowledged the proposal from [comment 4](https://labs.riseup.net/code/issues/8447#note-4).
+ - We acknowledged the proposal from [[!tails_ticket 8447#note-4 desc="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](https://labs.riseup.net/code/issues/8443#note-9).
+ - We acknowledged the proposal from [[!tails_ticket 8443#note-9 desc="comment 9"]].
- DrWhax will try to do it for 1.3.
# [[!tails_ticket 8510 desc="Reconsider distributing a hybrid ISO image"]]
diff --git a/wiki/src/contribute/meetings/201611.mdwn b/wiki/src/contribute/meetings/201611.mdwn
new file mode 100644
index 0000000..95186a3
--- /dev/null
+++ b/wiki/src/contribute/meetings/201611.mdwn
@@ -0,0 +1,33 @@
+[[!meta title="November 2016 online meeting"]]
+
+[[!toc levels=1]]
+
+# Volunteers to handle "[Hole in the roof](https://labs.riseup.net/code/versions/198)" tickets this month
+
+Nobody volunteered to handle additional Hole in the roof tickets.
+
+# Volunteers to handle important tickets flagged for next release but without assignee
+
+There were no such tickets.
+
+# Availability and plans until the next meeting
+
+* intrigeri will be around this month, He is already booked with
+ a Strech sprint and a reproducible ISO sprint, but will help people
+ who want to prepare pieces for our next SponsorS grant proposal.
+* sycamoreone will try to do some Python porting and research for the
+ randomness seeding.
+* u will also have more time for Tails until the end of December.
+
+# [[!tails_ticket 11859 desc="Trusting Tails Installer & Ubuntu PPA"]]
+
+We decided that more info and in particular a clear user-story is
+needed here. The user-story should make clear how users will use the
+proposed solutions to improve security. The ticket will be set to
+"Needs more info".
+
+# [[!tails_ticket 11841 desc="Consider shipping libgail-common"]]
+
+We decided that this is a can of worm that we should not open.
+Many GTK applications produce spurious text on stdout, but this is in
+general not a problem. So, this ticket will be rejected.
diff --git a/wiki/src/contribute/meetings/201612.mdwn b/wiki/src/contribute/meetings/201612.mdwn
new file mode 100644
index 0000000..7cf24cb
--- /dev/null
+++ b/wiki/src/contribute/meetings/201612.mdwn
@@ -0,0 +1,64 @@
+[[!meta title="December 2016 online meeting"]]
+
+[[!toc levels=1]]
+
+# Holes on the roof
+
+Alant is working on the Greeter, so [[!tails_ticket 5318]] is for him.
+
+# Volunteers to handle important tickets flagged for next release, but without assignee
+
+After some looking we got 3 tickets assigned:
+
+- [[!tails_ticket 12015 desc="Upgrade Tor to 0.2.8.10"]] for intrigeri
+- [[!tails_ticket 7700 desc="Have a distribution mechanism for the revocation
+ certificate of our signing key"]] and [[!tails_ticket 11920 desc="Remove
+ the FAQ on commercial SSL certificate once boum.org has Let's Encrypt"]] for
+ sajolida
+
+# Availability for next month:
+
+- intrigeri: as usual; plans: a Stretch sprint, 1 invoicing round, and helping
+ people give good input to sajolida for next SponsorS proposal. And attend 60%
+ of the reproducible builds summit!
+- spriver: probably attending CCC, work a bit on #11669 again, and on #11822
+- sajolida: availability: continue with the donation campaign and prepare the
+ OTF concept note
+- alant: I'll be randomly available as usual, but I'll participate to the next
+ Stretch sprint to include the revamped greeter in it, plus help on other
+ topics I'm knowledgeable about
+- emmapeel will have some time for docs
+
+# Tickets discussed
+
+## [[!tails_ticket 11884 desc="Document using Tor bridges to work around missing entry guards"]]
+
+The proposal has some sense, but then we will be providing the information only
+for power users, not for the majority of Tails users.
+As in some months we will actually be able to provide entry guards, then we
+decided to give it a low priority and suggest to put it in "Confirmation
+attacks" on doc/about/warning, mentioning the risk/benefit decision one must
+make about location tracking.
+
+## [[!tails_ticket 11969 desc="Revisit scrolling settings, Stretch edition"]]
+
+We decided to rather drop our customisation (as most of the OS are doing natural
+scrolling now) and let GNOME+libinput do what they think is best, i.e. natural
+scrolling in most cases.
+
+This way we keep reducing our delta with upstream.
+
+## [[!tails_ticket 12003 desc="Set a warning message in RCs and alpha releases from Tails 3.0 on"]]
+
+We realised that we were maybe exaggerating when giving ISO images for testing
+to the users, at least for Tails 3.x, and that the ISOs could sometimes have
+bugs and glitches but they are passing all the security tests, at least on the
+Release Candidates (RC) or for example Tails 3.0~alpha1.
+
+So maybe there are some bugs but not security issues.
+
+We decided to change the background to grey and add a warning saying:
+
+"Hey, you are running Tails 3.0 alpha. It is safe to use but might still be
+broken in many ways. Report any problems to tails-testers@boum.org" and a grey
+background.
diff --git a/wiki/src/contribute/meetings/201701.mdwn b/wiki/src/contribute/meetings/201701.mdwn
new file mode 100644
index 0000000..93c58fb
--- /dev/null
+++ b/wiki/src/contribute/meetings/201701.mdwn
@@ -0,0 +1,42 @@
+[[!meta title="January 2017 online meeting"]]
+
+[[!toc levels=1]]
+
+# Availability for next month:
+
+- u will be available and will try to close tickets in January, and
+ work on a Debian backport for Tails Installer.
+- spriver will keep at [[!tails_ticket 9833 desc="Replace AdBlock Plus with uBlock Origin"]]
+ and work on her other tickets.
+- anonym will come back to his "office hours" in two days and will work on [[!tails_ticket 7870 desc="Include OnionShare"]]
+ + test suite stuff + Tails 2.10 release management + mentoring spriver for #9833.
+- emmapeel will not have much time, she will do the December report.
+
+# Holes on the roof
+
+- anonym has one assigned
+
+# Volunteers to handle important tickets flagged for next release, but without assignee
+
+- All the tickets for Tails 2.10 were already assigned!
+
+# Tickets discussed
+
+## [[!tails_ticket 6972 desc="Create a 'Sponsors' page"]]
+
+- We discussed for a while about the pros and cons of a sponsor page.
+- We agreed easily on no sponsors on the homepage, although on a separated page
+ it would be nice.
+- We don't publish the minimum amount needed to be there, as it can change.
+- Many other questions arise:
+ - We renovate the page each year, like the press page?
+ - Should past sponsors be listed?
+ - How should we communicate to interested sponsors (have a public policy)?
+
+We want somebody to write a text that can be sent to possible sponsors
+explaining how this works.
+
+## [[!tails_ticket 12076 desc="Have a sponsor per release"]]
+
+We discussed it a bit, in general we didn't liked the idea, but we didn't
+reach a proper conclusion.
diff --git a/wiki/src/contribute/release_process.mdwn b/wiki/src/contribute/release_process.mdwn
index f741c9c..b458c8e 100644
--- a/wiki/src/contribute/release_process.mdwn
+++ b/wiki/src/contribute/release_process.mdwn
@@ -23,7 +23,7 @@ the scripts snippets found on this page:
* version numbers (see [[contribute/release_schedule#versioning]]):
export VERSION=$(dpkg-parsechangelog -SVersion)
- export TAG=$(echo "$VERSION" | sed -e 's,~,-,')
+ export TAG=$(echo "${VERSION:?}" | sed -e 's,~,-,')
export PREVIOUS_VERSION=$(dpkg-parsechangelog --offset 1 --count 1 -SVersion)
* `NEXT_PLANNED_VERSION`: set to the version number of the next Tails release
@@ -56,12 +56,6 @@ Pre-freeze
The [[contribute/working_together/roles/release_manager]] role
documentation has more tasks that should be done early enough.
-Update Tor Browser preferences
-------------------------------
-
-* update `extensions.adblockplus.currentVersion` in
- `config/chroot_local-includes/etc/tor-browser/profile/preferences/0000tails.js`
-
Update Icedove preferences
------------------------------
@@ -138,33 +132,41 @@ Common steps for point and major releases
Reset the release branch's `config/base_branch`:
- echo "${RELEASE_BRANCH}" > config/base_branch && \
+ echo "${RELEASE_BRANCH:?}" > config/base_branch && \
git commit config/base_branch \
- -m "Restore ${RELEASE_BRANCH}'s base branch."
+ -m "Restore ${RELEASE_BRANCH:?}'s base branch."
Update included files
=====================
-AdBlock patterns
+uBlock patterns and settings file
----------------
-Patterns are stored in
-`config/chroot_local-includes/etc/tor-browser/profile/adblockplus/`.
+The patterns+settings file is stored as a converted sqlite text dump in
+`config/chroot_local-includes/usr/share/tails/ublock-origin/ublock0.dump`.
1. Boot Tails
-2. Start the tor Browser and open *Tools* → *Addons*
-3. Select *Adblock Plus* in extensions
-4. Open *Preferences* → *Filter preferences…*
-5. For each filters, click *Actions* → *Update filters*
-6. Close the Tor Browser
-7. Copy the `.tor-browser/profile.default/adblockplus/patterns.ini` from
- this Tor Browser instance to the
- `config/chroot_local-includes/etc/tor-browser/profile/adblockplus`
- directory in the Tails Git checkout.
+2. Start the Tor Browser and open the uBlock dashboard by clicking on the uBlock icon.
+3. Select the tab *3rd-party filters*
+4. Click on the button *Update now* to update all used patterns
+5. Close the Tor Browser
+7. Copy the `.tor-browser/profile.default/extension-data/ublock0.sqlite`
+ from this Tor Browser instance into the root of Tails' Git repo and
+ run the following command:
+
+ echo '.dump' | sqlite3 ublock0.sqlite | \
+ grep -v "cached_asset_content://cache://compiled-" | \
+ awk '!/^INSERT/; /^INSERT/ {print $0 | "sort -n"}' | \
+ sed 's_\\n_\\n\r\n_g' | \
+ sed "/^INSERT INTO \"settings\" VALUES('\(remoteBlacklists\|cached_asset_entries\)'/"'s_,_,\r\n_g' > \
+ config/chroot_local-includes/usr/share/tails/ublock-origin/ublock0.dump
+
8. Commit:
- git commit -m 'Update AdBlock Plus patterns.' \
- config/chroot_local-includes/etc/tor-browser/profile/adblockplus/patterns.ini
+ git commit -m 'Update uBlock Origin patterns + settings file.' \
+ config/chroot_local-includes/usr/share/tails/ublock-origin/ublock0.dump
+
+9. Remove the original `ublock0.sqlite` from the Git root.
Upgrade bundled binary Debian packages
--------------------------------------
@@ -181,7 +183,7 @@ and then run the `import-translations` script that is in the
main Tails repository. For example:
cd whisperback
- "$RELEASE_CHECKOUT"/import-translations
+ "${RELEASE_CHECKOUT:?}"/import-translations
If the `import-translations` script fails to import translations for
the current package, manually copy updated PO files from the
@@ -193,7 +195,7 @@ Add and commit.
Then check the PO files:
- "$RELEASE_CHECKOUT"/submodules/jenkins-tools/slaves/check_po
+ "${RELEASE_CHECKOUT:?}"/submodules/jenkins-tools/slaves/check_po
Correct any displayed error, then commit the changes if any.
@@ -226,7 +228,7 @@ Pull updated translations for languages translated in Transifex,
refresh the code PO files,
and commit the result, including new PO files:
- cd "$RELEASE_CHECKOUT" && \
+ cd "${RELEASE_CHECKOUT:?}" && \
./import-translations && \
./refresh-translations && \
./submodules/jenkins-tools/slaves/check_po && \
@@ -288,7 +290,7 @@ Update other base branches
4. Push the modified branches to Git:
git push origin \
- "${RELEASE_BRANCH}:${RELEASE_BRANCH}" \
+ "${RELEASE_BRANCH:?}:${RELEASE_BRANCH:?}" \
feature/stretch:feature/stretch \
devel:devel
@@ -301,8 +303,8 @@ Changelog
Remove the placeholder entry for next release in `debian/changelog`,
and then:
- git checkout "$RELEASE_BRANCH" && \
- ./release $VERSION $PREVIOUS_VERSION
+ git checkout "${RELEASE_BRANCH:?}" && \
+ ./release ${VERSION:?} ${PREVIOUS_VERSION:?}
This populates the Changelog with the Git log entries.
@@ -316,15 +318,15 @@ Then, gather other useful information from:
Volume Assistant, etc.);
* the diff between the previous version's `.packages` file and the one
from the to-be-released ISO;
-* the "Fix committed" section on the *Release Manager View for $VERSION*
+* the "Fix committed" section on the *Release Manager View for ${VERSION:?}*
in Redmine.
Finally, sanity check the version and commit:
- if [ "$(dpkg-parsechangelog -SVersion)" = "${VERSION}" ]; then
- git commit debian/changelog -m "Update changelog for $VERSION."
+ if [ "$(dpkg-parsechangelog -SVersion)" = "${VERSION:?}" ]; then
+ git commit debian/changelog -m "Update changelog for ${VERSION:?}."
else
- echo 'Error: version mismatch: please compare $VERSION with the last entry in debian/changelog'
+ echo 'Error: version mismatch: please compare ${VERSION:?} with the last entry in debian/changelog'
fi
Included website
@@ -348,12 +350,12 @@ matches the date of the future signature.
RELEASE_DATE='2015-11-03'
- echo "$VERSION" > wiki/src/inc/stable_i386_version.html
- echo -n "$RELEASE_DATE" > wiki/src/inc/stable_i386_date.html
- sed -ri "s%news/version_.*]]%news/version_$VERSION]]%" wiki/src/inc/stable_i386_release_notes.*
- $EDITOR wiki/src/inc/*.html
+ echo "${VERSION:?}" > wiki/src/inc/stable_i386_version.html
+ echo -n "${RELEASE_DATE:?}" > wiki/src/inc/stable_i386_date.html
+ sed -ri "s%news/version_.*]]%news/version_${VERSION:?}]]%" wiki/src/inc/stable_i386_release_notes.*
+ ${EDITOR:?} wiki/src/inc/*.html
./build-website
- git commit wiki/src/inc/ -m "Update version and date for $VERSION."
+ git commit wiki/src/inc/ -m "Update version and date for ${VERSION:?}."
### features and design documentation
@@ -369,7 +371,7 @@ the new release. This e.g. ensures that the RC call for translation
points translators to up-to-date PO files:
./build-website && git add wiki/src && git commit -m 'Update website PO files.'
- git push origin "${RELEASE_BRANCH}:${RELEASE_BRANCH}"
+ git push origin "${RELEASE_BRANCH:?}:${RELEASE_BRANCH:?}"
Call for translation
====================
@@ -383,7 +385,7 @@ translators|contribute/how/translate]].
To get a list of changes on the website:
- git diff --stat ${PREVIOUS_VERSION}.. -- \
+ git diff --stat ${PREVIOUS_VERSION:?}.. -- \
*.{mdwn,html} \
':!wiki/src/blueprint*' \
':!wiki/src/contribute*' \
@@ -405,16 +407,16 @@ and a good practice is to import it to a tmpfs to limit the risks that
the private key material is written to disk:
export GNUPGHOME=$(mktemp -d)
- sudo mount -t ramfs ramfs "$GNUPGHOME"
- sudo chown $(id -u):$(id -g) "$GNUPGHOME"
- sudo chmod 0700 "$GNUPGHOME"
- gpg --homedir $HOME/.gnupg --export $TAILS_SIGNATURE_KEY | gpg --import
+ sudo mount -t ramfs ramfs "${GNUPGHOME:?}"
+ sudo chown $(id -u):$(id -g) "${GNUPGHOME:?}"
+ sudo chmod 0700 "${GNUPGHOME:?}"
+ gpg --homedir ${HOME:?}/.gnupg --export ${TAILS_SIGNATURE_KEY:?} | gpg --import
gpg --import path/to/private-key
Let's also ensure that strong digest algorithms are used for our
signatures, like the defaults we set in Tails:
- cp config/chroot_local-includes/etc/skel/.gnupg/gpg.conf "$GNUPGHOME"
+ cp config/chroot_local-includes/etc/skel/.gnupg/gpg.conf "${GNUPGHOME:?}"
Build the almost-final image
============================
@@ -426,15 +428,15 @@ Build the almost-final image
4. Record where the manifest of needed packages is stored:
export PACKAGES_MANIFEST=XXX ; \
- [ -f "$PACKAGES_MANIFEST" ] || echo "ERROR: PACKAGES_MANIFEST is incorrect"
+ [ -f "${PACKAGES_MANIFEST:?}" ] || echo "ERROR: PACKAGES_MANIFEST is incorrect"
Tag the release in Git
======================
- git tag -u "$TAILS_SIGNATURE_KEY" \
- -m "tagging version ${VERSION}" "${TAG}" && \
- git push --tags origin "${RELEASE_BRANCH}"
+ git tag -u "${TAILS_SIGNATURE_KEY:?}" \
+ -m "tagging version ${VERSION:?}" "${TAG:?}" && \
+ git push --tags origin "${RELEASE_BRANCH:?}"
(Pushing the tag is needed so that the APT repository is updated, and
the Tails APT configuration works at build and boot time. It might be
@@ -453,7 +455,7 @@ Prepare the versioned APT suites
* Prepare tagged snapshots of upstream APT repositories:
- ./bin/tag-apt-snapshots "$PACKAGES_MANIFEST" "$TAG"
+ ./bin/tag-apt-snapshots "${PACKAGES_MANIFEST:?}" "${TAG:?}"
Note:
@@ -521,46 +523,50 @@ suite should be ready, so it is time to:
* Mark the version as "released" in the changelog:
dch --release --no-force-save-on-release --maintmaint
- git commit -m "Mark Tails ${VERSION} as released." debian/changelog
+ git commit -m "Mark Tails ${VERSION:?} as released." debian/changelog
* tag the release *again*, with all included files in:
- git tag -f -u "$TAILS_SIGNATURE_KEY" \
- -m "tagging version ${VERSION}" "${TAG}" && \
- git push origin "${RELEASE_BRANCH}" && \
+ git tag -f -u "${TAILS_SIGNATURE_KEY:?}" \
+ -m "tagging version ${VERSION:?}" "${TAG:?}" && \
+ git push origin "${RELEASE_BRANCH:?}" && \
git push --tags --force
* check out the release tag:
- git checkout "${TAG}"
+ git checkout "${TAG:?}"
* build the final image!
* compare the new build manifest with the one from the previous,
- almost final build; they should be identical
+ almost final build; they should be identical, except that the
+ `debian-security` serial/reference might be higher. To ensure we get
+ the final build's .build-manifest, please run:
+
+ export PACKAGES_MANIFEST="${ARTIFACTS:?}/tails-i386-${VERSION:?}.iso.build-manifest"
* check out the release branch again:
- git checkout "${RELEASE_BRANCH}"
+ git checkout "${RELEASE_BRANCH:?}"
Generate the OpenPGP signatures and Torrents
============================================
First, create a directory with a suitable name and go there:
- mkdir "$ISOS/tails-i386-$VERSION" && \
- cd "$ISOS/tails-i386-$VERSION"
+ mkdir "${ISOS:?}/tails-i386-${VERSION:?}" && \
+ cd "${ISOS:?}/tails-i386-${VERSION:?}"
Second, move the built image to this brand new directory:
- mv "$ARTIFACTS/tails-i386-$VERSION.iso" \
- "$ISOS/tails-i386-$VERSION/"
+ mv "${ARTIFACTS:?}/tails-i386-${VERSION:?}.iso" \
+ "${ISOS:?}/tails-i386-${VERSION:?}/"
Third, generate detached OpenPGP signatures for the image to be
published, in the same directory as the image and with a `.sig`
extension; e.g.
- gpg --armor --default-key "$TAILS_SIGNATURE_KEY" --detach-sign *.iso
+ gpg --armor --default-key "${TAILS_SIGNATURE_KEY:?}" --detach-sign *.iso
rename 's,\.asc$,.sig,' *.asc
Fourth, go up to the parent directory, create a `.torrent` file and
@@ -570,14 +576,14 @@ check the generated `.torrent` files metainfo:
mktorrent \
-a 'udp://tracker.torrent.eu.org:451' \
-a 'udp://tracker.coppersurfer.tk:6969' \
- "tails-i386-${VERSION}" && \
- transmission-show tails-i386-$VERSION.torrent
+ "tails-i386-${VERSION:?}" && \
+ transmission-show tails-i386-${VERSION:?}.torrent
Lastly, let's set some variables to be used later:
- ISO_PATH="${ISOS}/tails-i386-${VERSION}/tails-i386-${VERSION}.iso"
- ISO_SHA256SUM="$(sha256sum "${ISO_PATH}" | cut -f 1 -d ' ' | tr -d '\n')"
- ISO_SIZE_IN_BYTES="$(stat -c %s "${ISO_PATH}")"
+ ISO_PATH="${ISOS:?}/tails-i386-${VERSION:?}/tails-i386-${VERSION:?}.iso"
+ ISO_SHA256SUM="$(sha256sum "${ISO_PATH:?}" | cut -f 1 -d ' ' | tr -d '\n')"
+ ISO_SIZE_IN_BYTES="$(stat -c %s "${ISO_PATH:?}")"
<a id="prepare-iuk"></a>
@@ -587,12 +593,16 @@ Prepare incremental upgrades
Build the Incremental Upgrade Kits
----------------------------------
+Incremental upgrades may be skipped if the delta is too big (like when
+migrating to a new Debian release) or if there are changes outside of
+the scope for IUKs (like partition table changes). Use common sense!
+
Use `tails-create-iuk` to build the following IUKs:
-* From the previous stable release, e.g. 1.0 to 1.0.1 or 1.0 to
- 1.0.1~rc1. This may be skipped if the delta is too big (like when
- migrating to a new Debian release) or if there are changes outside
- of the scope for IUKs (like partition table changes).
+* From the two previous *planned* releases, and any emergency releases
+ in between and after. This should be, more or less, all releases for
+ the last 12 weeks (although irregularities in Firefox release
+ schedule may add or remove a few weeks).
* From the last RC for the version being released, e.g. 1.0~rc1 to
1.0. This should be done even if there was no IUK generated from the
@@ -600,16 +610,19 @@ Use `tails-create-iuk` to build the following IUKs:
that'll be used for the incremental upgrade paths to the
next version.
-Example (for RC, replace `$PREVIOUS_VERSION` with e.g. `$VERSION~rc1`
-below):
+Include each such version in a white-space separated list called
+`IUK_SOURCE_VERSIONS`, (e.g. `IUK_SOURCE_VERSIONS="2.8 2.9 2.9.1 2.10~rc1"`)
+and run the following:
- sudo su -c "cd $IUK_CHECKOUT && \
- PERL5LIB=\"$PERL5LIB_CHECKOUT/lib\" \
- ./bin/tails-create-iuk \
- --squashfs-diff-name \"$VERSION.squashfs\" \
- --old-iso \"$ISOS/tails-i386-$PREVIOUS_VERSION/tails-i386-$PREVIOUS_VERSION.iso\" \
- --new-iso \"$ISOS/tails-i386-$VERSION/tails-i386-$VERSION.iso\" \
- --outfile \"$ISOS/Tails_i386_${PREVIOUS_VERSION}_to_${VERSION}.iuk\""
+ for source_version in ${IUK_SOURCE_VERSIONS}; do
+ sudo su -c "cd ${IUK_CHECKOUT:?} && \
+ PERL5LIB=\"${PERL5LIB_CHECKOUT:?}/lib\" \
+ ./bin/tails-create-iuk \
+ --squashfs-diff-name \"${VERSION:?}.squashfs\" \
+ --old-iso \"${ISOS:?}/tails-i386-${source_version:?}/tails-i386-${source_version:?}.iso\" \
+ --new-iso \"${ISOS:?}/tails-i386-${VERSION:?}/tails-i386-${VERSION:?}.iso\" \
+ --outfile \"${ISOS:?}/Tails_i386_${source_version:?}_to_${VERSION:?}.iuk\""
+ done
Note that developer tools for creating IUK and upgrade-description
files were only tested on Debian sid. It should hopefully work well on
@@ -632,21 +645,21 @@ Prepare upgrade-description files
* create a new upgrade-description for the version being released,
that expresses that *no* upgrade is available for that one yet.
- This is what `tails-iuk-generate-ugrade-description-files` tool
+ This is what `tails-iuk-generate-upgrade-description-files` tool
does:
- ( cd $IUK_CHECKOUT && \
+ ( cd ${IUK_CHECKOUT:?} && \
./bin/tails-iuk-generate-upgrade-description-files \
- --version "$VERSION" \
- --next-version "$NEXT_PLANNED_VERSION" \
- --next-version "${NEXT_PLANNED_VERSION}~rc1" \
- --next-version "${VERSION}.1" \
- --iso "$ISOS/tails-i386-$VERSION/tails-i386-$VERSION.iso" \
- --previous-version "$PREVIOUS_VERSION" \
- --previous-version "${VERSION}~rc1" \
- --iuks "$ISOS" \
- --release-checkout "$RELEASE_CHECKOUT" \
- --major-release "$MAJOR_RELEASE" \
+ --version "${VERSION:?}" \
+ --next-version "${NEXT_PLANNED_VERSION:?}" \
+ --next-version "${NEXT_PLANNED_VERSION:?}~rc1" \
+ --next-version "${VERSION:?}.1" \
+ --iso "${ISOS:?}/tails-i386-${VERSION:?}/tails-i386-${VERSION:?}.iso" \
+ --previous-version "${PREVIOUS_VERSION:?}" \
+ --previous-version "${VERSION:?}~rc1" \
+ --iuks "${ISOS:?}" \
+ --release-checkout "${RELEASE_CHECKOUT:?}" \
+ --major-release "${MAJOR_RELEASE:?}" \
)
Note:
@@ -667,23 +680,23 @@ Prepare upgrade-description files
* If preparing a release candidate, add `--channel alpha`
* If preparing a release candidate, drop all `--next-version`
arguments, and instead pass (**untested!**)
- `--next-version $(echo $VERSION | sed -e 's,~rc*$,,')`
+ `--next-version $(echo ${VERSION:?} | sed -e 's,~rc.*$,,')`
* If preparing a point-release, pass neither
- `--next-version "${VERSION}.1"`,
- nor `--next-version "${VERSION}.1~rc1"`
+ `--next-version "${VERSION:?}.1"`,
+ nor `--next-version "${VERSION:?}.1~rc1"`
1. Create an armoured detached signature for each created or modified
upgrade-description file.
- find "${RELEASE_CHECKOUT}/wiki/src/upgrade/" \
+ find "${RELEASE_CHECKOUT:?}/wiki/src/upgrade/" \
-type f -name upgrades.yml | \
while read udf; do
- if [ -n "$(git status --porcelain "${udf}")" ]; then
- gpg -u "${TAILS_SIGNATURE_KEY}" --armor --detach-sign "${udf}"
- mv "${udf}.asc" "${udf}.pgp"
+ if [ -n "$(git status --porcelain "${udf:?}")" ]; then
+ gpg -u "${TAILS_SIGNATURE_KEY:?}" --armor --detach-sign "${udf:?}"
+ mv "${udf:?}.asc" "${udf:?}.pgp"
( \
- cd $IUK_CHECKOUT && \
- ./bin/tails-iuk-check-upgrade-description-file "${udf}" \
+ cd ${IUK_CHECKOUT:?} && \
+ ./bin/tails-iuk-check-upgrade-description-file "${udf:?}" \
) || break
fi
done
@@ -692,32 +705,41 @@ Prepare upgrade-description files
signatures to the Git branch used to prepare the release (`stable`
or `testing`):
- ( cd "$RELEASE_CHECKOUT" && git add wiki/src/upgrade && \
- git commit -m "Update upgrade-description files." )
+ ( \
+ cd "${RELEASE_CHECKOUT:?}" && git add wiki/src/upgrade && \
+ git commit -m "Update upgrade-description files." && \
+ git push origin ${RELEASE_BRANCH:?} \
+ )
1. If preparing a release candidate, move the generated or updated
- files to `$MASTER_CHECKOUT`, commit and push: given the updates are
+ files to `${MASTER_CHECKOUT:?}`, commit and push: given the updates are
advertised on the *alpha* channel, while all users use the *stable*
one by default, this will allow you to more easily test the IUK
without impacting anyone.
-XXX: Untested yet. This step was missing to test the incremental upgrades
-during the manual test suite, but then should we also document that once the
-release is out this UDF should be removed?
1. If preparing a point release, copy the generated UDF for the previous
release in the alpha channel in the master branch, modify its content
accordingly, sign it, commit and push
- stable_udf="wiki/src/upgrade/v1/Tails/${PREVIOUS_VERSION}/i386/stable/upgrades.yml"
- alpha_udf="wiki/src/upgrade/v1/Tails/${PREVIOUS_VERSION}/i386/alpha/upgrades.yml"
-
- cd $MASTER_CHECKOUT && \
- git show ${RELEASE_BRANCH}:${stable_udf} \
- | sed -e 's/channel: stable/channel: alpha/' > ${alpha_udf} && \
- gpg -u "${TAILS_SIGNATURE_KEY}" --armor --detach-sign ${alpha_udf} && \
- mv ${alpha_udf}.asc ${alpha_udf}.gpg && \
- git commit -m 'Add alpha UDF channel for ${PREVIOUS_VERSION} to ${VERSION}' \
- ${alpha_udf}* && git push origin master:master
+ # If more old versions are supported, add them (whitespace
+ # separated) to this variable
+ SUPPORTED_OLD_VERSIONS="${PREVIOUS_VERSION:?}"
+
+ ( \
+ cd ${MASTER_CHECKOUT:?} && \
+ git fetch && \
+ for old_version in ${SUPPORTED_OLD_VERSIONS:?}; do
+ stable_udf="wiki/src/upgrade/v1/Tails/${old_version:?}/i386/stable/upgrades.yml" && \
+ alpha_udf="wiki/src/upgrade/v1/Tails/${old_version:?}/i386/alpha/upgrades.yml" && \
+ git show origin/${RELEASE_BRANCH:?}:${stable_udf:?} \
+ | sed -e 's/channel: stable/channel: alpha/' > ${alpha_udf:?} && \
+ gpg -u "${TAILS_SIGNATURE_KEY:?}" --armor --detach-sign ${alpha_udf:?} && \
+ mv ${alpha_udf:?}.asc ${alpha_udf:?}.pgp && \
+ git add ${alpha_udf:?}* ; \
+ done && \
+ git commit -m "Add incremental upgrades on the alpha channel for Tails ${VERSION:?}" && \
+ git push origin master:master \
+ )
Prepare the ISO description file for DAVE
@@ -727,18 +749,18 @@ If preparing a RC, skip this part.
Update the ISO description file (IDF) used by the browser extension:
- cat > "$RELEASE_CHECKOUT"/wiki/src/install/v1/Tails/i386/stable/latest.yml <<EOF
+ cat > "${RELEASE_CHECKOUT:?}"/wiki/src/install/v1/Tails/i386/stable/latest.yml <<EOF
---
build-target: i386
channel: stable
product-name: Tails
- version: '${VERSION}'
+ version: '${VERSION:?}'
target-files:
- sha256: ${ISO_SHA256SUM}
- size: ${ISO_SIZE_IN_BYTES}
- url: http://dl.amnesia.boum.org/tails/stable/tails-i386-${VERSION}/tails-i386-${VERSION}.iso
+ size: ${ISO_SIZE_IN_BYTES:?}
+ url: http://dl.amnesia.boum.org/tails/stable/tails-i386-${VERSION:?}/tails-i386-${VERSION:?}.iso
EOF
- ( cd "${RELEASE_CHECKOUT}" && \
+ ( cd "${RELEASE_CHECKOUT:?}" && \
git add wiki/src/install/v1/Tails/i386/stable/latest.yml && \
git commit -m "Update IDF file for DAVE." )
@@ -759,10 +781,10 @@ Test them with a BitTorrent client running in a different place.
## Download and seed image from lizard
- scp "$ISOS/tails-i386-$VERSION.torrent" \
+ scp "${ISOS:?}/tails-i386-${VERSION:?}.torrent" \
bittorrent.lizard: && \
ssh bittorrent.lizard \
- transmission-remote --add tails-i386-$VERSION.torrent \
+ transmission-remote --add tails-i386-${VERSION:?}.torrent \
--find /var/lib/transmission-daemon/downloads/
<a id="publish-iuk"></a>
@@ -776,32 +798,32 @@ rsync.lizard:
ssh lizard.tails.boum.org \
scp -3 -r \
- bittorrent.lizard:/var/lib/transmission-daemon/downloads/tails-i386-$VERSION \
+ bittorrent.lizard:/var/lib/transmission-daemon/downloads/tails-i386-${VERSION:?} \
rsync.lizard:
ssh rsync.lizard << EOF
sudo chown -R root:rsync_tails \
- tails-i386-$VERSION \
- Tails_i386_${PREVIOUS_VERSION}_to_${VERSION}.iuk && \
+ tails-i386-${VERSION:?} \
+ Tails_i386_${PREVIOUS_VERSION:?}_to_${VERSION:?}.iuk && \
sudo chmod -R u=rwX,go=rX \
- tails-i386-$VERSION \
- Tails_i386_${PREVIOUS_VERSION}_to_${VERSION}.iuk && \
- sudo mv tails-i386-$VERSION \
- /srv/rsync/tails/tails/$DIST/ && \
- sudo mv Tails_i386_${PREVIOUS_VERSION}_to_${VERSION}.iuk \
- /srv/rsync/tails/tails/$DIST/iuk/
+ tails-i386-${VERSION:?} \
+ Tails_i386_${PREVIOUS_VERSION:?}_to_${VERSION:?}.iuk && \
+ sudo mv tails-i386-${VERSION:?} \
+ /srv/rsync/tails/tails/${DIST:?}/ && \
+ sudo mv Tails_i386_${PREVIOUS_VERSION:?}_to_${VERSION:?}.iuk \
+ /srv/rsync/tails/tails/${DIST:?}/iuk/
EOF
Update the time in `project/trace` file on the primary rsync mirror
and on the live wiki (even for a release candidate):
TRACE_TIME=$(date +%s) &&
- echo $TRACE_TIME | ssh rsync.lizard "cat > /srv/rsync/tails/tails/project/trace" && \
- [ -n "$MASTER_CHECKOUT" ] && \
- echo $TRACE_TIME > "$MASTER_CHECKOUT/wiki/src/inc/trace" &&
+ echo ${TRACE_TIME:?} | ssh rsync.lizard "cat > /srv/rsync/tails/tails/project/trace" && \
+ [ -n "${MASTER_CHECKOUT:?}" ] && \
+ echo ${TRACE_TIME:?} > "${MASTER_CHECKOUT:?}/wiki/src/inc/trace" &&
(
- cd "$MASTER_CHECKOUT" && \
+ cd "${MASTER_CHECKOUT:?}" && \
git commit wiki/src/inc/trace \
- -m "Updating trace file after uploading $VERSION." && \
+ -m "Updating trace file after uploading ${VERSION:?}." && \
git push origin master
)
@@ -816,7 +838,7 @@ Update the website and Git repository
=====================================
What follows in this section happens on the release branch in
-`$RELEASE_CHECKOUT`.
+`${RELEASE_CHECKOUT:?}`.
If preparing a final release
----------------------------
@@ -826,36 +848,36 @@ Skip this part if preparing a RC.
Rename the `.packages` file to remove the `.iso` and build date parts
of its name:
- mv "$ARTIFACTS"/tails-i386-"$VERSION".iso.packages \
- "$ARTIFACTS/tails-i386-$VERSION.packages"
+ mv "${ARTIFACTS:?}"/tails-i386-"${VERSION:?}".iso.packages \
+ "${ARTIFACTS:?}/tails-i386-${VERSION:?}.packages"
Rename the manifest of needed packages as well:
- mv "$PACKAGES_MANIFEST" "$ARTIFACTS/tails-i386-$VERSION.build-manifest"
+ mv "${PACKAGES_MANIFEST:?}" "${ARTIFACTS:?}/tails-i386-${VERSION:?}.build-manifest"
Copy the `.iso.sig`, `.build-manifest`, `.packages`, `.torrent` and
`.torrent.sig` files into the website repository:
- cp "$ISOS/tails-i386-$VERSION/tails-i386-$VERSION.iso.sig" \
- "$ARTIFACTS/tails-i386-$VERSION.build-manifest" \
- "$ARTIFACTS/tails-i386-$VERSION.packages" \
- "$ISOS/tails-i386-$VERSION.torrent" \
- "$RELEASE_CHECKOUT/wiki/src/torrents/files/"
+ cp "${ISOS:?}/tails-i386-${VERSION:?}/tails-i386-${VERSION:?}.iso.sig" \
+ "${ARTIFACTS:?}/tails-i386-${VERSION:?}.build-manifest" \
+ "${ARTIFACTS:?}/tails-i386-${VERSION:?}.packages" \
+ "${ISOS:?}/tails-i386-${VERSION:?}.torrent" \
+ "${RELEASE_CHECKOUT:?}/wiki/src/torrents/files/"
Remove from `wiki/src/torrents/files/` any remaining file from the
previous release (including any RC).
Update the size of the ISO image in `inc/*`:
- LC_NUMERIC=C ls -l -h $ISOS/tails-i386-$VERSION/tails-i386-$VERSION.iso | \
+ LC_NUMERIC=C ls -l -h ${ISOS:?}/tails-i386-${VERSION:?}/tails-i386-${VERSION:?}.iso | \
cut -f 5 -d ' ' | sed -r 's/(.+)([MG])/\1 \2iB/' \
- > "$RELEASE_CHECKOUT/wiki/src/inc/stable_i386_iso_size.html"
+ > "${RELEASE_CHECKOUT:?}/wiki/src/inc/stable_i386_iso_size.html"
Generate the expected signature verification output:
- gpg --keyid-format 0xlong --verify "${ISO_PATH}.sig" "${ISO_PATH}" 2>&1 | \
+ gpg --keyid-format 0xlong --verify "${ISO_PATH:?}.sig" "${ISO_PATH:?}" 2>&1 | \
sed 's/ /\&nbsp;/g;s/</\&lt;/;s/>/\&gt;/;s/$/<br\/>/g' > \
- "$RELEASE_CHECKOUT/wiki/src/inc/stable_i386_gpg_signature_output.html"
+ "${RELEASE_CHECKOUT:?}/wiki/src/inc/stable_i386_gpg_signature_output.html"
Update the [[support/known_issues]] page:
@@ -863,7 +885,7 @@ Update the [[support/known_issues]] page:
- Remove older known issues that are fixed by the new release.
Write the announcement for the release in
-`wiki/src/news/version_$TAG.mdwn`. See the [[release notes
+`wiki/src/news/version_${TAG:?}.mdwn`. See the [[release notes
documentation|contribute/how/documentation/release_notes]]
XXX: we should probably merge that into the above liked documentation.
@@ -881,7 +903,7 @@ XXX: we should probably merge that into the above liked documentation.
Write an announcement listing the security bugs affecting the previous
version in
-`wiki/src/security/Numerous_security_holes_in_${PREVIOUS_VERSION}.mdwn`
+`wiki/src/security/Numerous_security_holes_in_${PREVIOUS_VERSION:?}.mdwn`
in order to let the users of the old versions
know that they have to upgrade. Date it a few days before the ISO
image to be released was *built*. Including:
@@ -904,12 +926,12 @@ Skip this part if preparing a final release.
Copy the `.iso.sig` file into the website repository:
- cp "${ISO_PATH}.sig" \
- "$ISOS/tails-i386-${VERSION}.torrent" \
- "${MASTER_CHECKOUT}/wiki/src/torrents/files/"
+ cp "${ISO_PATH:?}.sig" \
+ "${ISOS:?}/tails-i386-${VERSION:?}.torrent" \
+ "${MASTER_CHECKOUT:?}/wiki/src/torrents/files/"
Write the announcement for the release in
-`$MASTER_CHECKOUT/wiki/src/news/test_$TAG.mdwn`, including:
+`${MASTER_CHECKOUT:?}/wiki/src/news/test_${TAG:?}.mdwn`, including:
- Update the `meta title` directive.
- Update the `meta date` directive.
@@ -922,7 +944,7 @@ Write the announcement for the release in
references to links:
sed -i 's@#\([0-9]\{4,5\}\)@[[!tails_ticket \1]]@g' \
- wiki/src/news/test_${TAG}.mdwn
+ wiki/src/news/test_${TAG:?}.mdwn
In any case
-----------
@@ -936,7 +958,7 @@ release out officially.
Then, record the last commit before putting the release out for real:
git add wiki/src && \
- git commit -m "releasing version ${VERSION}"
+ git commit -m "releasing version ${VERSION:?}"
Testing
=======
@@ -975,9 +997,10 @@ Wait for the HTTP mirrors to catch up
Test downloading the ISO and IUK over HTTP.
-Make sure every active mirror in the pool has the new version:
+Make sure every active mirror in the pool has the new version (when
+releasing an RC, add `--channel alpha`):
- ./check-mirrors.rb --allow-multiple --fast tails-i386-$VERSION
+ ./check-mirrors.rb --allow-multiple --fast tails-i386-${VERSION:?}
Ask <tails-mirrors@boum.org> to drop those that are lagging behind and
notify their administrators.
@@ -1000,13 +1023,13 @@ If preparing a release candidate, just push the `master` branch:
If preparing an actual release, push the last commits to our Git
repository like this:
- ( cd "$RELEASE_CHECKOUT" && \
- git push origin "$RELEASE_BRANCH:$RELEASE_BRANCH" \
+ ( cd "${RELEASE_CHECKOUT:?}" && \
+ git push origin "${RELEASE_BRANCH:?}:${RELEASE_BRANCH:?}" \
devel:devel \
) && \
- ( cd "$MASTER_CHECKOUT" && \
+ ( cd "${MASTER_CHECKOUT:?}" && \
git fetch && \
- git merge "origin/$RELEASE_BRANCH" && \
+ git merge "origin/${RELEASE_BRANCH:?}" && \
git push origin master:master \
)
@@ -1021,7 +1044,7 @@ tracker. For a list of candidates, see:
* the [issues in *Fix committed*
status](https://labs.riseup.net/code/projects/tails/issues?query_id=111);
-* the "Fix committed" section on the *Release Manager View for $VERSION*
+* the "Fix committed" section on the *Release Manager View for ${VERSION:?}*
in Redmine.
Then, mark the just-released Redmine milestone as done: go to the
@@ -1036,18 +1059,18 @@ this release.
find wiki/src/{doc,support} -name "*.mdwn" -o -name "*.html" | xargs cat | \
ruby -e 'puts STDIN.read.scan(/\[\[!tails_ticket\s+(\d+)[^\]]*\]\]/)' | \
while read ticket; do
- url="https://labs.riseup.net/code/issues/${ticket}"
- url_content=$(curl --fail --silent ${url})
+ url="https://labs.riseup.net/code/issues/${ticket:?}"
+ url_content=$(curl --fail --silent ${url:?})
if [ "${?}" -ne 0 ]; then
- echo "Failed to fetch ${url} so manually investigate #${ticket}" >&2
+ echo "Failed to fetch ${url:?} so manually investigate #${ticket:?}" >&2
continue
fi
- ticket_status=$(echo "${url_content}" | \
+ ticket_status=$(echo "${url_content:?}" | \
sed -n 's,^.*<th class="status">Status:</th><td class="status">\([^<]\+\)</td>.*$,\1,p')
- if [ "${ticket_status}" != "New" ] && \
- [ "${ticket_status}" != "Confirmed" ] && \
- [ "${ticket_status}" != "In Progress" ]; then
- echo "It seems ticket #${ticket} has been fixed (Status: ${ticket_status}) so please find all instances in the wiki and fix them. Ticket URL: ${url}"
+ if [ "${ticket_status:?}" != "New" ] && \
+ [ "${ticket_status:?}" != "Confirmed" ] && \
+ [ "${ticket_status:?}" != "In Progress" ]; then
+ echo "It seems ticket #${ticket:?} has been fixed (Status: ${ticket_status:?}) so please find all instances in the wiki and fix them. Ticket URL: ${url:?}"
fi
done
@@ -1099,9 +1122,6 @@ to do it.
Amnesia news
------------
-XXX: During the 2.7 release, the related email was not sent to the list,
-despite the news having the announce tag.
-
The release announcement are automatically sent to `amnesia-news@`
(thanks to the `announce` flag) on an hourly basis, but it will be
stuck in the moderation
@@ -1118,6 +1138,8 @@ this, and skip what does not make sense for a RC.
stable release on the mirrors.
1. Remove any remaining RC for the just-published release from
the mirrors.
+1. Revert the commits adding `alpha` channel incremental upgrades to
+ the just released version.
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:
@@ -1141,14 +1163,14 @@ this, and skip what does not make sense for a RC.
1. Delete Git branches that were merged:
bare_repo=$(mktemp -d)
- (cd "$MASTER_CHECKOUT" && git fetch) && \
- (cd "$MASTER_CHECKOUT" && git submodule update) && \
- git clone --bare --reference "$MASTER_CHECKOUT" \
+ (cd "${MASTER_CHECKOUT:?}" && git fetch) && \
+ (cd "${MASTER_CHECKOUT:?}" && git submodule update) && \
+ git clone --bare --reference "${MASTER_CHECKOUT:?}" \
boum_org_amnesia@webmasters.boum.org:wiki.git \
- "$bare_repo" && \
+ "${bare_repo:?}" && \
PYTHONPATH=lib/python3 ./bin/delete-merged-git-branches \
- --repo "$bare_repo" && \
- rm -rf "$bare_repo"
+ --repo "${bare_repo:?}" && \
+ rm -rf "${bare_repo:?}"
1. Remove all old versions in `wiki/src/upgrade/v1/Tails` and
`debian/changelog` that were never released. Explanation: the
@@ -1171,27 +1193,27 @@ this, and skip what does not make sense for a RC.
the dates must be ~six weeks in the future). Look carefully at the
output of this command:
- git checkout "$RELEASE_BRANCH" && \
+ git checkout "${RELEASE_BRANCH:?}" && \
(
cd config/APT_snapshots.d && \
for ARCHIVE in * ; do
- SERIAL="$(cat ${ARCHIVE}/serial)"
- if [ "${SERIAL}" = 'latest' ]; then
+ SERIAL="$(cat ${ARCHIVE:?}/serial)"
+ if [ "${SERIAL:?}" = 'latest' ]; then
EXPIRY='never'
- if [ "${ARCHIVE}" != 'debian-security' ]; then
- echo "Warning: origin '${ARCHIVE}' is using the 'latest' snapshot, which is unexpected" >&2
+ if [ "${ARCHIVE:?}" != 'debian-security' ]; then
+ echo "Warning: origin '${ARCHIVE:?}' is using the 'latest' snapshot, which is unexpected" >&2
fi
else
- EXPIRY="$(curl --silent "http://time-based.snapshots.deb.tails.boum.org/debian/dists/${RELEASE_BRANCH}/snapshots/${SERIAL}/Release" | sed -n 's/^Valid-Until:\s\+\(.*\)$/\1/p')"
+ EXPIRY="$(curl --silent "http://time-based.snapshots.deb.tails.boum.org/debian/dists/${RELEASE_BRANCH:?}/snapshots/${SERIAL:?}/Release" | sed -n 's/^Valid-Until:\s\+\(.*\)$/\1/p')"
fi
- echo "Origin '${ARCHIVE}' uses snapshot '${SERIAL}' which expires on: ${EXPIRY}"
+ echo "Origin '${ARCHIVE:?}' uses snapshot '${SERIAL:?}' which expires on: ${EXPIRY:?}"
done
)
1. Push the resulting branches.
1. Make sure Jenkins manages to build all updated major branches fine:
<https://jenkins.tails.boum.org/>.
-1. Delete the _Release Manager View for $VERSION_ Redmine custom query.
+1. Delete the _Release Manager View for ${VERSION_:?} Redmine custom query.
1. Ensure the next few releases have their own _Release Manager View_.
1. On the [[!tails_roadmap]], update the *Due date* for the *Holes
in the Roof* so that this section appears after the next release.
diff --git a/wiki/src/contribute/release_process/icedove.mdwn b/wiki/src/contribute/release_process/icedove.mdwn
index f06b38e..4de875b 100644
--- a/wiki/src/contribute/release_process/icedove.mdwn
+++ b/wiki/src/contribute/release_process/icedove.mdwn
@@ -30,27 +30,27 @@ released:
1. Let's update our branch to the new version:
- git checkout tails/jessie && git merge origin/tails/jessie
+ git checkout tails/jessie && git merge origin/tails/jessie && \
git merge --no-edit "${TAG}"
Now you most likely will have to deal with a merge conflict in
debian/changelog -- just reorder the entries chronologically. Then
let's release a new version:
- TAILS_VERSION="1:${VERSION}~deb8u1+tails1"
- DISTRIBUTION="feature-icedove-${VERSION}"
+ TAILS_VERSION="1:${VERSION}~deb8u1+tails1" && \
+ DISTRIBUTION="feature-icedove-${VERSION}" && \
dch --newversion "${TAILS_VERSION}" --force-bad-version \
--distribution "${DISTRIBUTION}" --force-distribution \
- "Rebuild Icedove with Tails' secure autoconfiguration patches."
+ "Rebuild Icedove with Tails' secure autoconfiguration patches." && \
git commit debian/changelog \
- -m "document changes and release ${TAILS_VERSION}"
+ -m "document changes and release ${TAILS_VERSION}" && \
gbp buildpackage --git-debian-branch=tails/jessie \
--git-sign-tags --git-tag-only
1. Fetch the Debian sources to be used for the build:
- ICEDOVE_SOURCES="$(mktemp -d)"
- GIT_DIR="$(pwd)"
+ ICEDOVE_SOURCES="$(mktemp -d)" && \
+ GIT_DIR="$(pwd)" && \
cd "${ICEDOVE_SOURCES}" && \
apt source icedove="1:${VERSION}" && \
cp icedove_*.orig*.tar.xz "${GIT_DIR}/.." && \
@@ -68,13 +68,21 @@ released:
1. Include all sources in the `.changes` file:
- CHANGES_FILE="../icedove_${VERSION}~deb8u1+tails1_i386.changes"
+ CHANGES_FILE="../icedove_${VERSION}~deb8u1+tails1_i386.changes" && \
changestool "${CHANGES_FILE}" includeallsources
+1. Due to [[!tails_ticket 11531]] we won't be able to push the tag
+ generated by `gbp` so we have to replace it with a differently
+ named tag:
+
+ NEW_TAG="$(echo ${TAG} | sed 's/1%//')" && \
+ git tag -s "${NEW_TAG}" -m "icedove Debian release 1:${VERSION}" "${TAG}" && \
+ TAG="${NEW_TAG}"
+
1. Git push and upload packages:
- git push origin "${TAG}" tails/jessie
- debsign "${CHANGES_FILE}"
+ git push origin "${TAG}" tails/jessie && \
+ debsign "${CHANGES_FILE}" && \
dupload --to tails "${CHANGES_FILE}"
At the moment pushing `TAG` may fail due to
diff --git a/wiki/src/contribute/release_process/tails-installer.mdwn b/wiki/src/contribute/release_process/tails-installer.mdwn
index f32adef..5c9a0f8 100644
--- a/wiki/src/contribute/release_process/tails-installer.mdwn
+++ b/wiki/src/contribute/release_process/tails-installer.mdwn
@@ -63,8 +63,8 @@ targeted at current Tails, as said above. More specifically:
* The `upstream/3.x+dfsg`, `upstream/4.x+dfsg`, etc. branches are what we tell `gbp`
to use as its "upstream" branch. Make sure to check them out when setting up the repository
for the first time.
-* For Ubuntu, we want to support the current Ubuntu version (currently `wily`), the
- upcoming version, currently (`xenial`) and the current LTS, from 16.04 on (currently
+* For Ubuntu, we want to support the current Ubuntu version (currently `yakkety`), the
+ upcoming version (currently `zesty`), and the current LTS (currently
`xenial`).
We do not maintain any Git branches related to Ubuntu releases, as simply the changelog
entries are modified.
@@ -197,6 +197,23 @@ Add a signed tag to the Git repository and push the changes:
"$PACKAGING_BRANCH" \
pristine-tar
+If you are a member of the Debian pkg-privacy team
+--------------------------------------------------
+
+Add the remote:
+
+ git remote add debian ssh://git.debian.org/git/pkg-privacy/packages/tails-installer.git
+
+Then push:
+
+ git push --tags debian "$UPSTREAM_BRANCH" \
+ "$PACKAGING_BRANCH" \
+ pristine-tar
+
+Never force push! If `git push` fails you may have to merge back in
+e.g. `debian/pristine-tag` into your local `pristine-tar` and push
+again. Also push it to `origin`, in that case.
+
Add the Debian package to Tails
-------------------------------
@@ -244,7 +261,7 @@ You'll need to configure the dput tool to upload to the PPA and put into
[ppa-tails-installer]
fqdn = ppa.launchpad.net
- method = sftp
+ method = ftp
incoming = ~tails-team/ubuntu/tails-installer/
login = your_launchpad_id
allow_unsigned_uploads = 0
diff --git a/wiki/src/contribute/release_process/test.mdwn b/wiki/src/contribute/release_process/test.mdwn
index db35c0c..36956eb 100644
--- a/wiki/src/contribute/release_process/test.mdwn
+++ b/wiki/src/contribute/release_process/test.mdwn
@@ -166,7 +166,7 @@ security critical bugs were fixed.
# APT (automate: [[!tails_ticket 8164 desc="#8164"]])
- grep -r deb.tails.boum.org /etc/apt/sources.list*
+ 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.
@@ -305,13 +305,16 @@ language. You *really* have to reboot between each language.
browser. Verify that you can install the Firefox Addon. Start
downloading a Tails image and copy the used mirror URL.
- The URL should only start with dl.amnesia.boum.org if Javascript
- is disabled in your browser. Otherwise it should contain a mirror
- URL from <https://tails.boum.org/mirrors.json>
+ is disabled in your browser (requires a restart!). Otherwise it should
+ contain a mirror URL from <https://tails.boum.org/mirrors.json>
- Verify that pausing and resuming the download from this URL works.
- Verify that when you start the download, you can see it appear in
the download list (Ctrl+Shift+Y).
* Test a disabled mirror (Possible only in FF > 51 because of
<https://bugzilla.mozilla.org/show_bug.cgi?id=1275289>.)
+ - Disabled mirrors have `"weight": 0` in
+ https://tails.boum.org/mirrors.json so just pick one of them. If
+ there's none, skip this test.
- Do not use Firefox over Tor.
- To disable Firefox's internal DNS cache, navigate to
`about:config` and set these prefererences:
@@ -325,6 +328,10 @@ language. You *really* have to reboot between each language.
used mirror to 127.0.0.1.
- Now reload the download page, and try to resume the download
again.
+ XXX: How is it ensured that the disabled mirror we picked above is
+ used?
- In the Firefox console (Ctrl+Shift+J) you should see the
- `mirror.blob` variable pointing to a different mirror. This
- should work.
+ `mirror.blob` variable pointing to a different mirror. This should
+ work.
+ XXX: Please provide more instructions for how to find this
+ variable, possibly with a (large but shortened) example.
diff --git a/wiki/src/contribute/release_process/test/automated_tests.mdwn b/wiki/src/contribute/release_process/test/automated_tests.mdwn
index ff184f4..9053dce 100644
--- a/wiki/src/contribute/release_process/test/automated_tests.mdwn
+++ b/wiki/src/contribute/release_process/test/automated_tests.mdwn
@@ -350,25 +350,6 @@ Although very rare, the remote shell can get into a state where it
stops responding, resulting in the test suite waiting for a response
forever.
-## Host-to-guest filesystem shares are incompatibile with snapshots
-
-Filesystem shares cannot (due to QEMU limitations) be added to an
-active VM, and cannot (due to QEMU limitations) be active
-(i.e. mounted) during a snapshot save. For this reason, don't use
-filesystem shares in combination with snapshots. For more
-information, see [[!tails_ticket 5571]].
-
-On a more practical note, you *can* add a filesystem share if you
-restore a snapshot and then power off the computer, which still is
-worth it when there's a big setup cost, e.g. when Tails is running
-from USB with persistence enabled. So something like this is valid,
-for example:
-
- Given Tails has booted without network from a USB drive with a persistent partition and stopped at Tails Greeter's login screen
- And I shutdown Tails and wait for the computer to power off
- And I setup some filesystem share ...
- And I start Tails from USB drive "current" with network unplugged and I login with persistence enabled
-
## Plugging SATA drives
When creating a disk (at least when backed by a `raw` image) via the
diff --git a/wiki/src/contribute/release_process/test/usage.mdwn b/wiki/src/contribute/release_process/test/usage.mdwn
index d9a2756..971f5e4 100644
--- a/wiki/src/contribute/release_process/test/usage.mdwn
+++ b/wiki/src/contribute/release_process/test/usage.mdwn
@@ -122,6 +122,13 @@ by the local configuration file:
failure screenshots, pcap files and disk images. Defaults to
`"/tmp/TailsToaster"`.
+* `NOTIFY_USER_COMMAND`: String value. This arbitrary shell command
+ will be executed whenever `pause()` is called, e.g. on test failure
+ when `INTERACTIVE_DEBUGGING` (`--interactive-debugging`) is
+ enabled. This is pretty useful when multitasking with long test
+ suite runs, so you immediately are notified when a test fails (or
+ when you reached a temporary `pause()` breakpoint).
+
## "Secret" configuration
This section describes the formats for all secret configurations that
@@ -200,3 +207,13 @@ where `$TYPE` is `SSH` or `SFTP`. Secrets must be specified for both `SSH` and
`SFTP`. If `port` is not specified, `22`will be used.
The SSH test expects the remote system to have a default `bash` shell prompt.
+
+### Icedove
+
+These settings are required for `icedove.feature`. The format is:
+
+ Icedove:
+ address: user@example.com
+ password: trustno1
+
+The email account's inbox must contain at least one email at all times.
diff --git a/wiki/src/contribute/release_process/tor-browser.mdwn b/wiki/src/contribute/release_process/tor-browser.mdwn
index 2fde56c..ea4c920 100644
--- a/wiki/src/contribute/release_process/tor-browser.mdwn
+++ b/wiki/src/contribute/release_process/tor-browser.mdwn
@@ -176,7 +176,7 @@ Import a new set of Tor Browser tarballs
cd "$TAILS_GIT_REPO" && git checkout "$TBB_IMPORT_BRANCH"
TBB_TARBALLS_BASE_URL="$(cat "${TBB_DIST_URL_FILE}" | sed "s,^http://,https://,")"
current_branch=$(git -C "$TAILS_GIT_REPO" branch | awk '/^\* / { print $2 }')
- for branch in "$current_branch" feature/8183-64bit-userspace ; do
+ for branch in "$current_branch" feature/stretch ; do
git -C "$TAILS_GIT_REPO" show "$branch:$TBB_SHA256SUMS_FILE" \
| while read expected_sha256 tarball; do
(
@@ -197,7 +197,7 @@ Import a new set of Tor Browser tarballs
cd "$TBB_ARCHIVE" && \
mkdir "$TBB_VERSION" && cd "$TBB_VERSION" && \
- git annex import --duplicate "$TMPDIR/"*
+ git annex import --duplicate "$TMPDIR/"* "$TAILS_GIT_REPO/"sha256sums-*
Commit and push your changes
----------------------------
@@ -225,10 +225,10 @@ Adjust the URL in the main Git repository
cd "$TAILS_GIT_REPO" && \
git checkout "$TBB_IMPORT_BRANCH"
current_branch=$(git branch | awk '/^\* / { print $2 }')
- for branch in "$current_branch" feature/8183-64bit-userspace ; do
+ for branch in "$current_branch" feature/stretch ; do
git checkout "$branch" && \
echo "http://torbrowser-archive.tails.boum.org/${TBB_VERSION}/" > \
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." && \
+ -m "Fetch Tor Browser from our own archive."
done
diff --git a/wiki/src/contribute/working_together/roles/test_suite.mdwn b/wiki/src/contribute/working_together/roles/test_suite.mdwn
index f10513e..af78480 100644
--- a/wiki/src/contribute/working_together/roles/test_suite.mdwn
+++ b/wiki/src/contribute/working_together/roles/test_suite.mdwn
@@ -14,8 +14,15 @@ test suite by:
- Writing tests for regressions, unexpected or unbudgeted features, etc.
+ - Refactoring the test suite code as needed, whenever we're trying
+ to solve another practical problem, and the lack of refactoring
+ gets in the way. In other words: refactoring will be dealt with by
+ test suite maintainers as a integral part of modifying code, and
+ not as a separate task.
+
Writing tests for new features should be estimated and budgeted each
-time we write grant applications for such features.
+time we write grant applications for such features. Same for the
+refactoring that such work may require.
Writing tests to replace our old manual tests should also be budgeted
separately.