Commit 803081ca authored by intrigeri's avatar intrigeri
Browse files

Merge branch 'stable' into testing

parents 788e67bf 13eaed5e
...@@ -383,7 +383,7 @@ Then /^a Tails persistence partition exists on USB drive "([^"]+)"$/ do |name| ...@@ -383,7 +383,7 @@ Then /^a Tails persistence partition exists on USB drive "([^"]+)"$/ do |name|
end end
Given /^I enable persistence$/ do Given /^I enable persistence$/ do
@screen.wait_and_click('TailsGreeterPersistencePassphrase.png', 10) @screen.wait_and_click('TailsGreeterPersistencePassphrase.png', 60)
@screen.type(@persistence_password + Sikuli::Key.ENTER) @screen.type(@persistence_password + Sikuli::Key.ENTER)
@screen.wait('TailsGreeterPersistenceUnlocked.png', 30) @screen.wait('TailsGreeterPersistenceUnlocked.png', 30)
end end
......
# /dev/random and /dev/urandom radomness seeding in Tails # /dev/random and /dev/urandom radomness seeding in Tails
/dev/random and /dev/urandom are special Linux devices that provide access from /dev/random and /dev/urandom are special Linux devices that provide
user land to the Linux kernel Cryptographically Secure Pseudo Random Number access from user land to the Linux kernel Cryptographically Secure
Generator (CSPRNG). This generator is used for almost every security protocol, Pseudo Random Number Generator (CSPRNG). This generator is used for
like TLS/SSL key generation, choosing TCP sequences, ASLR offsets, and GPG key almost every security protocol, like TLS/SSL key generation, choosing
generation [1]. In order for this CSPRNG to be really cryptographically secure, TCP sequences, ASLR offsets, and GPG key generation
it's recommended to seed it with a 'good' entropy source, even though The Linux [https://eprint.iacr.org/2006/086.pdf]. In order for this CSPRNG to
kernel collects entropy from several sources, for example keyboard typing, indeed be cryptographically secure, it's recommended to seed it with a
mouse movement, among others. 'good' entropy source, even though The Linux kernel collects entropy
from several sources, for example keyboard typing, mouse movement, among
Because of the Tails nature of being amnesic, and run from different type of others.
live devices (from DVDs to USB sticks), special care must be taken to ensure
the system still gets enough entropy and boots with enough randomness. This is Because of Tails' feature of being amnesic, and run from different types
not easy in the Tails context, where the system is almost always booting the of live devices (from DVDs to USB sticks), special care must be taken to
same way. Even the squashfs file is ordered to optimize boot time. ensure the system gets enough entropy and boots with enough randomness.
This proves to be hard within the Tails context, where the system is
Although these problem have been documented since a long time (see [7] and almost always booting the same way. Even the squashfs file is ordered to
[8]), there's not much done to tackle the problem. We looked at notes and optimize boot time.
research from LiveCD OS's and supply them here for completements sake. Whonix
has a [wiki page](https://www.whonix.org/wiki/Dev/Entropy) with some notes, and Although these problems have been documented since a long time (see
Qubes has tickets about this ([3],[4],[5] and [6]). [https://www.av8n.com/computer/htm/secure-random.htm] and
[http://www.av8n.com/computer/htm/fixup-live-cd.htm]), there's not much
done to tackle the problem. We looked at notes and research from LiveCD
OS's and supply them here for completeness' sake. Whonix has a [wiki
page](https://www.whonix.org/wiki/Dev/Entropy) with some notes, and
Qubes has tickets about this
([http://wiki.qubes-os.org/trac/ticket/673],
[https://github.com/QubesOS/qubes-issues/issues/1311],
[https://groups.google.com/forum/#!msg/qubes-devel/Q65boPAbqbE/9ZOZUInQCgAJ],
[https://groups.google.com/forum/#!topic/qubes-devel/5wI8ygbaohk]).
## Current situation ## Current situation
See the related [[design document|contribute/design/random]] See the related [[design document|contribute/design/random]]
Tails do not ship /var/lib/urandom/random-seed in the ISO, since it means Tails does not ship /var/lib/urandom/random-seed in the ISO, since it
shipping a fixed known value for every Tails installation which means its means shipping a fixed known value for every Tails installation, which
entropy contribution is zero, and breaks reproducibility of the ISO image. in turn means that entropy contribution would zero. Furthermore, this
breaks reproducibility of the ISO image.
Without this random seed, systemd-random-seed won't write anything to Without this random seed, systemd-random-seed won't write anything to
/dev/urandom, so we rely purely on the kernel CSPRNG and current system entropy /dev/urandom, so we rely purely on the kernel CSPRNG and current system entropy
...@@ -39,8 +49,8 @@ Tails ships Haveged and rngd since a while. Still there are concerns about ...@@ -39,8 +49,8 @@ Tails ships Haveged and rngd since a while. Still there are concerns about
Haveged's reliability to provide cryptographically secure randomness, and rngd Haveged's reliability to provide cryptographically secure randomness, and rngd
is only really useful when random generator devices are used. is only really useful when random generator devices are used.
Taking other measures to seed the Linux Kernel CSPRNG with good material is Taking other measures to seed the Linux Kernel CSPRNG with good material seems
something worst spending efforts on. worth spending efforts on.
## Use cases ## Use cases
...@@ -55,33 +65,33 @@ add one. ...@@ -55,33 +65,33 @@ add one.
On the other hand, that's not the installation method we want to support the On the other hand, that's not the installation method we want to support the
most, and probably not the most used when people want to secure other most, and probably not the most used when people want to secure other
communication types than HTTPS (e.g persistence is very usefull for OpenPGP key communication types than HTTPS (e.g persistence is very useful for OpenPGP key
storage and usage, chat account configuration, ...). storage and usage, chat account configuration, ...).
So we may eventually just document somewhere to users that they MUST NOT use So we may eventually just document somewhere to users that they MUST NOT use
this type of installation if they want to rely on good cryptograpy for their this type of installation if they want to rely on good cryptography for their
communications and key generation, or that they should wait after having communications and key generation, or that they should wait after having
interacting a long (but hard to define) time with the system so that it had time interacted a long (but hard to define) time with the system so that it had time
to collect entropy, and does not rely on the CSPRNG, Haveged and rngd only. to collect entropy, and does not rely on the CSPRNG, Haveged and rngd only.
We could also add some kind of notification to users when entropy gets too low, We could also add some kind of notification to users when entropy gets too low,
or just saying them that the way they use Tails is not compatible with strong or just tell them that the way they use Tails is not compatible with strong
cryptography. cryptography.
### Intermediary USB ### Intermediary USB
This type of installation is supposed to be used when people are installing This type of installation is supposed to be used when people are installing
Tails from another OS (except Debian and Ubuntu, where they can use the Tails Tails from another OS (except Debian and Ubuntu, where they can use the Tails
installer). In most case, this means having a bit by bit copy of the Tails ISO installer). In most cases, this means having a bit-by-bit copy of the Tails ISO
on the USB stick, except for Windows where we ask to use the [Universal USB on the USB stick, except for Windows where we ask to use the [Universal USB
Installer](http://www.pendrivelinux.com/universal-usb-installer-easy-as-1-2-3/) Installer](http://www.pendrivelinux.com/universal-usb-installer-easy-as-1-2-3/)
In this case the situation is pretty much the same than with the DVD one. No In this case the situation is pretty much the same than with the DVD one. No
seed, and adding one is very difficult if not impossible (except with the seed. And adding one is very difficult if not impossible (except with the
Windows installation where we may ask upstream to implement that in the Windows installation where we may ask upstream to implement that in the
Universal USB Installer, but well...). Universal USB Installer, but well...).
That's also not really the way we encourge users to use Tails, so as with DVD That's also not really the way we encourage users to use Tails, so as with DVD
there's maybe no point to fix the situation here, and the same workaround could there's maybe no point to fix the situation here, and the same workaround could
be applied (document it). be applied (document it).
...@@ -92,10 +102,11 @@ That's supposed to be the standard way to use Tails. ...@@ -92,10 +102,11 @@ That's supposed to be the standard way to use Tails.
Note that in this case, there are two situations: booting this installation Note that in this case, there are two situations: booting this installation
with persistence enabled, and without. with persistence enabled, and without.
It is worth noting too that the first time this Tails installation is booted, It is worth noting that the first time this Tails installation is
most of the time the first step is to configure persistence, which means booted, most of the time the first step is to configure persistence,
creating an encrypted partition. At this step though, there is at the moment which means creating an encrypted partition. At this step though, there
probably very little entropy, so this may weaken the LUKS volume encryption. is probably very little entropy at this moment, which may weaken the
LUKS volume encryption.
### Virtual Machines ### Virtual Machines
...@@ -120,6 +131,9 @@ partition is created. ...@@ -120,6 +131,9 @@ partition is created.
### Use the Tails installer to create a better seed [[!tails_ticket 11897]] ### Use the Tails installer to create a better seed [[!tails_ticket 11897]]
Note that we'll likely soon distribute a USB image and won't use Tails
installer anymore for creating Tails devices. [[!tails_ticket 15292]]
Tails installer can be used on Debian and Ubuntu, and is the tool people Tails installer can be used on Debian and Ubuntu, and is the tool people
running OSX or Windows are told to use to install their final Tails running OSX or Windows are told to use to install their final Tails
USB stick with, by using an intermediary Tails to create the final USB. USB stick with, by using an intermediary Tails to create the final USB.
...@@ -128,32 +142,34 @@ Tails installer could store a seed in the FAT filesystem of the system ...@@ -128,32 +142,34 @@ Tails installer could store a seed in the FAT filesystem of the system
partition. That would workaround this first boot problem not handled by the partition. That would workaround this first boot problem not handled by the
persistence option. persistence option.
We can't sadly update this seed while running Tails, as mounting RW the system We sadly can't update this seed while running Tails, as read-write mounting the system
FAT partition during a Tails session does not work. So the question whether updating it FAT partition during a Tails session does not work. So the question whether updating it
or not is open. or not is open.
If we want to do so, we'll have to update it at the system shutdown. This will If we want to do so, we'll have to update it at the system shutdown. This will
mean remount this partition, write the new random seed, then unmount it and mean remount this partition, write the new random seed, then unmount it and
start the shutdown of the system. Obviously we can do this only in normal start the shutdown of the system. Obviously we can do this only in normal
shutdown process, and will have to avoid it in emergency shutdown mode. shutdown process, and we'll have to avoid it in emergency shutdown mode.
We may alternatively not update it, and use it only when the persistence is not We may alternatively not update it, and use it only when the persistence is not
enabled. That would still be a unique source of entropy per Tails installation, enabled. That would still be a unique source of entropy per Tails installation,
so that would be a better situation that the current one. so that would be a better situation than the current one.
One drawback: this would break the ability to verify this system partition with One drawback: this would break the ability to verify this system partition with
a simple shasum operation. a simple shasum operation.
### Use stronger/more entropy collectors [[!tails_ticket 5650]] ### Use stronger/more entropy collectors [[!tails_ticket 5650]]
As already stated, Tails run Haveged, and rngd (since 2.6 for the later). As already stated, Tails runs Haveged, and rngd (since 2.6 for the later).
We may want to add other sources though, given there are concerns about Haveged, We may want to add other sources though, given there are concerns about Haveged,
and rngd starts only when a hardware RNG is detected, which is not so often the and rngd starts only when a hardware RNG is detected, which is not so often the
case. case.
XXX: It would be nice to have a study (read: a survey of packages, etc) of all the XXX: It would be nice to have a study (read: a survey of packages, etc)
useful entropy gathering daemons that might be of use on a Tails system. (and have this tested on computers with/without intel rng or things like an entropykey) of all the useful entropy gathering daemons that might be of use on a
Tails system. (and have this tested on computers with/without intel rng
or things like an entropykey)
An evaluation of some of them [has been done An evaluation of some of them [has been done
already](https://volumelabs.net/best-random-data-software/) already](https://volumelabs.net/best-random-data-software/)
...@@ -167,26 +183,26 @@ Possible candidates: ...@@ -167,26 +183,26 @@ Possible candidates:
* randomsound: probably a bad idea in the Tails context as we're discussing a * randomsound: probably a bad idea in the Tails context as we're discussing a
Greeter option to deactivate the microphone. Greeter option to deactivate the microphone.
### Block booting till enough entropy has been gathered ### Block booting until enough entropy has been gathered
One way to ensure Tails is booting with enough entropy would be to block during One way to ensure Tails is booting with enough entropy would be to block
the boot if the system is lacking of it. the boot while the system is lacking it.
But this brings questions about how to interact correctly with the users, But this brings questions about how to interact correctly with the users,
as blocking without notifications would be terrible UX. Also Tails boot time is as blocking without notifications would be terrible UX. Also Tails boot time is
a bit long already, and this may grow it quite a bit more again. a bit long already, and this may grow it quite a bit more again.
XXX: So before going on, we need a bit more data about the state of the entropy when XXX: So before going on, we need a bit more data about the state of the entropy when
Tails boot, specially now that we have several entropy collector daemons. It may Tails boots, especially now that we have several entropy collector daemons. It may
very well be that this case do not happen anymore. And if it is, we need to know very well be that this case does not happen anymore. And if it does, we need to know
on average how much time that blocking would last. [Sycamoreone] [[!tails_ticket on average how much time that blocking would last. [[!tails_ticket
11758]] 11758]]
### Regulary check available entropy and notify if low ### Regulary check available entropy and notify if low
An idea that has been mentioned several time is to have a service that An idea that has been mentioned several times is to have a service that
check if the available entropy is high enough, and notify the user if checks if the available entropy is high enough, and notifies the user if
it's not the case. One downside, is that observing the entropy pool costs it's not the case. One downside is, that observing the entropy pool costs
randomness, so this may have to be implemented with care or is worth randomness, so this may have to be implemented with care or is worth
discussing/researching the costs/benefits. discussing/researching the costs/benefits.
...@@ -195,15 +211,8 @@ discussing/researching the costs/benefits. ...@@ -195,15 +211,8 @@ discussing/researching the costs/benefits.
This is about [[!tails_ticket 7642]], [[!tails_ticket 7675]], This is about [[!tails_ticket 7642]], [[!tails_ticket 7675]],
[[!tails_ticket 6116]], [[!tails_ticket 11897]] and friends. [[!tails_ticket 6116]], [[!tails_ticket 11897]] and friends.
## References ## More references
* [1] <https://eprint.iacr.org/2006/086.pdf> * <https://eprint.iacr.org/2013/338.pdf>
* [2] <https://eprint.iacr.org/2013/338.pdf> * <https://www.python.org/dev/peps/pep-0506/>
* [3] <http://wiki.qubes-os.org/trac/ticket/673> * <https://docs.python.org/2/library/os.html#os.urandom>
* [4] <https://github.com/QubesOS/qubes-issues/issues/1311>
* [5] <https://groups.google.com/forum/#!msg/qubes-devel/Q65boPAbqbE/9ZOZUInQCgAJ>
* [6] <https://groups.google.com/forum/#!topic/qubes-devel/5wI8ygbaohk>
* [7] <https://www.av8n.com/computer/htm/secure-random.htm>
* [8] <http://www.av8n.com/computer/htm/fixup-live-cd.htm>
* [9] <https://www.python.org/dev/peps/pep-0506/>
* [10]<https://docs.python.org/2/library/os.html#os.urandom>
...@@ -328,11 +328,11 @@ just appeared: ...@@ -328,11 +328,11 @@ just appeared:
After a new Tails release is out After a new Tails release is out
-------------------------------- --------------------------------
If you just put out a final release: ### If you just put out a final release
* [[merge `stable` or `testing` into * [[merge `stable` or `testing` into
`devel`|APT_repository/custom#workflow-merge-main-branch]] `devel`|APT_repository/custom#workflow-merge-main-branch]]
* increment the version number in devel's `debian/changelog` to match * increment the version number in `devel`'s `debian/changelog` to match
the next major release, so that the next major release, so that
next builds from the `devel` branch do not use the APT suite meant next builds from the `devel` branch do not use the APT suite meant
for the last release: for the last release:
...@@ -356,20 +356,6 @@ If you just put out a final release: ...@@ -356,20 +356,6 @@ If you just put out a final release:
git commit debian/changelog \ git commit debian/changelog \
-m "Add dummy changelog entry for ${NEXT_PLANNED_MINOR_VERSION:?}." -m "Add dummy changelog entry for ${NEXT_PLANNED_MINOR_VERSION:?}."
If you just released a RC (XXX: please automate these steps during the
3.2~rc1 release process, based on the above commands):
* add a dummy changelog entry (for the upcoming, non-RC version) in
the branch used for the release (`stable` or `testing`), so that the
next builds from it do not use the APT suite meant for the RC
* add a dummy changelog entry (for the release *after* the one you
released a RC for) in the branch used for the release (`stable` or
`testing`), so that the next builds from it do not use the APT suite
meant for the RC (XXX: I don't understand what this is about; is it
instead about adding an entry for that release on the `devel`
branch? -- intrigeri)
If the release was a major one, then: If the release was a major one, then:
1. [[Hard reset the stable APT suite to 1. [[Hard reset the stable APT suite to
...@@ -382,6 +368,30 @@ If the release was a major one, then: ...@@ -382,6 +368,30 @@ If the release was a major one, then:
git commit config/APT_overlays.d/ \ git commit config/APT_overlays.d/ \
-m "Empty the list of APT overlays: they were merged" -m "Empty the list of APT overlays: they were merged"
### Else, if you just released a RC
* increment the version number in `debian/changelog` on the branch
used for the release, to match the upcoming non-RC release, so that
the next builds from it do not use the APT suite meant for the RC:
cd "${RELEASE_CHECKOUT}" && \
git checkout "${RELEASE_BRANCH:?}" && \
dch --newversion "${NEXT_PLANNED_MAJOR_VERSION:?}" \
"Dummy entry for next release." && \
git commit debian/changelog \
-m "Add dummy changelog entry for ${NEXT_PLANNED_MAJOR_VERSION:?}."
* increment the version number in `devel`'s `debian/changelog` to
match the second next major release, so that images built from there
have the right version number:
cd "${RELEASE_CHECKOUT}" && \
git checkout devel && \
dch --newversion "${SECOND_NEXT_PLANNED_MAJOR_VERSION:?}" \
"Dummy entry for next release." && \
git commit debian/changelog \
-m "Add dummy changelog entry for ${SECOND_NEXT_PLANNED_MAJOR_VERSION:?}."
Giving access to a core developer Giving access to a core developer
--------------------------------- ---------------------------------
......
...@@ -4,10 +4,6 @@ All times are referenced to Berlin and Paris time. ...@@ -4,10 +4,6 @@ All times are referenced to Berlin and Paris time.
## 2018Q3 ## 2018Q3
* 2018-08-16: Build and upload tentative 3.9~rc1 ISO image — intrigeri
* 2018-08-17: Test and release 3.9~rc1 — intrigeri
* 2018-09-03, 19:00: [[Contributors meeting|contribute/meetings]] * 2018-09-03, 19:00: [[Contributors meeting|contribute/meetings]]
* 2018-09-04: Build and upload tentative 3.9 ISO image — intrigeri * 2018-09-04: Build and upload tentative 3.9 ISO image — intrigeri
...@@ -19,17 +15,17 @@ All times are referenced to Berlin and Paris time. ...@@ -19,17 +15,17 @@ All times are referenced to Berlin and Paris time.
* 2018-10-03, 19:00: [[Contributors meeting|contribute/meetings]] * 2018-10-03, 19:00: [[Contributors meeting|contribute/meetings]]
* 2018-10-23: **Release 3.10** (Firefox 60.3, bugfix release) — anonym is the RM * 2018-10-23: **Release 3.10** (Firefox 60.3, bugfix release)
* 2018-11-06, 19:00: [[Contributors meeting|contribute/meetings]] * 2018-11-06, 19:00: [[Contributors meeting|contribute/meetings]]
* 2018-12-03, 19:00: [[Contributors meeting|contribute/meetings]] * 2018-12-03, 19:00: [[Contributors meeting|contribute/meetings]]
* 2018-12-11: **Release 3.11** (Firefox 60.4, major release) — anonym is the RM * 2018-12-11: **Release 3.11** (Firefox 60.4, bugfix release)
## 2019Q1 ## 2019Q1
* 2019-01-29: **Release 3.12** (Firefox 60.5) * 2019-01-29: **Release 3.12** (Firefox 60.5, major release)
* 2019-03-19: **Release 3.13** (Firefox 60.6) * 2019-03-19: **Release 3.13** (Firefox 60.6)
......
...@@ -21,6 +21,8 @@ To release Tails you'll need some packages installed: ...@@ -21,6 +21,8 @@ To release Tails you'll need some packages installed:
`debian/control` in the `debian` branch of its repo) `debian/control` in the `debian` branch of its repo)
* `tails-perl5lib` dependencies (same trick as `tails-iuk` to get the * `tails-perl5lib` dependencies (same trick as `tails-iuk` to get the
list) list)
* `po4a` _from Stretch_: the version in testing/sid extracts Markdown headings
in a different way, which makes tons of strings fuzzy.
Environment Environment
=========== ===========
...@@ -38,7 +40,14 @@ the scripts snippets found on this page: ...@@ -38,7 +40,14 @@ the scripts snippets found on this page:
* `NEXT_PLANNED_VERSION`: set to the version number of the next Tails release * `NEXT_PLANNED_VERSION`: set to the version number of the next Tails release
(e.g. 0.23 when releasing 0.22.1, and 1.3 when releasing 1.2) (e.g. 0.23 when releasing 0.22.1, and 1.3 when releasing 1.2)
* `NEXT_PLANNED_MAJOR_VERSION`: set to the version number of the next * `NEXT_PLANNED_MAJOR_VERSION`: set to the version number of the next
*major* Tails release *major* Tails release; if you're preparing a RC for a major release,
use that major release; otherwise, use whatever the next planned
major release is
* `SECOND_NEXT_PLANNED_MAJOR_VERSION`: set to the version number of
the second next *major* Tails release; e.g. if preparing the RC for
the 3.9 major release, then set this to 3.12 (3.9 is the next major
release, 3.10 and 3.11 are bugfix releases, 3.12 is a major
release).
* `NEXT_PLANNED_MINOR_VERSION`: set to the version number of the next * `NEXT_PLANNED_MINOR_VERSION`: set to the version number of the next
*minor* Tails release; if the next release is a point-release, use *minor* Tails release; if the next release is a point-release, use
that one; otherwise, use `${VERSION}.1` that one; otherwise, use `${VERSION}.1`
...@@ -264,19 +273,22 @@ Update other base branches ...@@ -264,19 +273,22 @@ Update other base branches
1. Merge the release branch into `devel` following the instructions for 1. Merge the release branch into `devel` following the instructions for
[[merging base branches|APT_repository/custom#workflow-merge-main-branch]]. [[merging base branches|APT_repository/custom#workflow-merge-main-branch]].
2. Merge `devel` into `feature/buster`, *without* following the instructions for 2. [[Thaw|APT_repository/time-based snapshots#thaw]], on the devel
branch, the time-based APT repository snapshots that were used
during the freeze.
3. Merge `devel` into `feature/buster`, *without* following the instructions for
[[merging base branches|APT_repository/custom#workflow-merge-main-branch]]. [[merging base branches|APT_repository/custom#workflow-merge-main-branch]].
(For now `feature/buster` is handled as any other topic branch (For now `feature/buster` is handled as any other topic branch
forked off `devel`: its base branch is set to `devel`.) forked off `devel`: its base branch is set to `devel`.)
If the merge conflicts don't look like something you feel confident
resolving properly, abort this merge and let the Foundations
Team know.
3. Ensure that the release, `devel` and `feature/buster` branches 4. Ensure that the release, `devel` and `feature/buster` branches
have the expected content in `config/APT_overlays.d/`: e.g. it must have the expected content in `config/APT_overlays.d/`: e.g. it must
not list any overlay APT suite that has been merged already. not list any overlay APT suite that has been merged already.
4. [[Thaw|APT_repository/time-based snapshots#thaw]], on the devel
branch, the time-based APT repository snapshots that were used
during the freeze.
5. Push the modified branches to Git: 5. Push the modified branches to Git:
git push origin \ git push origin \
...@@ -493,19 +505,18 @@ SquashFS file order ...@@ -493,19 +505,18 @@ SquashFS file order
1. Start *Tor Browser*. 1. Start *Tor Browser*.
1. A few minutes later, once the `boot-profile` process has been 1. A few minutes later, once the `boot-profile` process has been
killed, retrieve the new sort file from `/var/log/boot-profile`. killed, retrieve the new sort file from `/var/log/boot-profile`.
1. Backup the old sort file: `cp config/binary_rootfs/squashfs.sort{,.old}`
1. Copy the new sort file to `config/binary_rootfs/squashfs.sort`. 1. Copy the new sort file to `config/binary_rootfs/squashfs.sort`.
1. Cleanup a bit: 1. Cleanup a bit:
- remove `var/log/live/config.pipe`: otherwise the boot is broken - remove `var/log/live/config.pipe`: otherwise the boot is broken
or super-slow or super-slow
- remove the bits about `kill-boot-profile` at the end: they're - remove the bits about `kill-boot-profile` at the end: they're
only useful when profiling the boot only useful when profiling the boot
1. Inspect the Git diff (including diff stat), apply common sense. 1. Inspect the Git diff (including diff stat), apply common sense:
The following command is also helpful but requires that you save a
copy of the old sort file into `/tmp/squashfs.sort.old`:
diff -NaurB \ diff -NaurB \
<( cut -d' ' -f1 /tmp/squashfs.sort.old | sort ) \ <( cut -d' ' -f1 config/binary_rootfs/squashfs.sort.old | sort ) \
<( cut -d' ' -f1 config/binary_rootfs/squashfs.sort | sort ) \ <( cut -d' ' -f1 config/binary_rootfs/squashfs.sort | sort ) \
| less | less
1. `git commit -m 'Updating SquashFS sort file' config/binary_rootfs/squashfs.sort` 1. `git commit -m 'Updating SquashFS sort file' config/binary_rootfs/squashfs.sort`
...@@ -540,10 +551,16 @@ suite should be ready, so it is time to: ...@@ -540,10 +551,16 @@ suite should be ready, so it is time to:
1. build the final image! 1. build the final image!
1. compare the new build manifest with the one from the previous, 1. Compare the new build manifest with the one from the previous,
almost final build; they should be identical, except that the almost final build:
`debian-security` serial might be higher. To ensure we publish
the final build's `.build-manifest`, please run: diff -Naur \
"${PACKAGES_MANIFEST:?}" \
"${ARTIFACTS:?}/tails-amd64-${VERSION:?}.iso.build-manifest"
They should be identical, except that the `debian-security` serial might be higher.
1. To ensure we publish the final build's `.build-manifest`, run:
export PACKAGES_MANIFEST="${ARTIFACTS:?}/tails-amd64-${VERSION:?}.iso.build-manifest" export PACKAGES_MANIFEST="${ARTIFACTS:?}/tails-amd64-${VERSION:?}.iso.build-manifest"
...@@ -769,7 +786,7 @@ Prepare upgrade-description files ...@@ -769,7 +786,7 @@ Prepare upgrade-description files
or RC), add `--channel alpha` or RC), add `--channel alpha`
* If preparing anything but a final release (e.g. an alpha, beta * If preparing anything but a final release (e.g. an alpha, beta
or RC), drop all `--next-version` or RC), drop all `--next-version`
arguments, and instead pass (**untested!**) arguments, and instead pass
`--next-version $(echo ${VERSION:?} | sed -e 's,~rc.*$,,')` `--next-version $(echo ${VERSION:?} | sed -e 's,~rc.*$,,')`
* Adjust `--next-version "${VERSION:?}.1"` so it matches the next * Adjust `--next-version "${VERSION:?}.1"` so it matches the next
potential emergency release. E.g. when releasing 3.7.1, potential emergency release. E.g. when releasing 3.7.1,
...@@ -807,13 +824,30 @@ Prepare upgrade-description files ...@@ -807,13 +824,30 @@ Prepare upgrade-description files
) )
1. If preparing anything but a final release (e.g. an alpha, beta 1. If preparing anything but a final release (e.g. an alpha, beta
or RC), copy the generated or updated files to or RC), copy the generated UDFs for the previous releases
`${MASTER_CHECKOUT:?}`, replace `channel: alpha` with `channel: to the *test* channel in `$MASTER_CHECKOUT`, modify their content
test`, sign them, commit and push. accordingly, sign them, commit and push:
1. Else, if preparing a final release, copy the generated UDF for the previous ( \
release to the *test* channel in `$MASTER_CHECKOUT`, modify its content cd ${MASTER_CHECKOUT:?} && \
accordingly, sign it, commit and push: git fetch && \
for old_version in ${IUK_SOURCE_VERSIONS:?}; do
alpha_udf="wiki/src/upgrade/v1/Tails/${old_version:?}/amd64/alpha/upgrades.yml" && \
test_udf="wiki/src/upgrade/v1/Tails/${old_version:?}/amd64/test/upgrades.yml" && \
mkdir -p "$(dirname "$test_udf")" && \
git show origin/${WEBSITE_RELEASE_BRANCH:?}:${alpha_udf:?} \
| sed -e 's/channel: alpha/channel: test/' > ${test_udf:?} && \
gpg -u "${TAILS_SIGNATURE_KEY:?}" --armor --detach-sign ${test_udf:?} && \
mv ${test_udf:?}.asc ${test_udf:?}.pgp && \
git add ${test_udf:?}* ; \
done && \
git commit -m "Add incremental upgrades on the test channel for Tails ${VERSION:?}" && \
git push origin master:master \
)