GitLab

Otherwise it would set the hardware clock to the system time, violating (a
strict interpretation of) our "don't leave traces on the hardware being used"
design goal.

Will-fix: #9364

The old live-config hook races with Tails Greeter, see #8941.

It warns that PulseAudio is configured for per-user sessions, which is the
default, and what we want => no need to let users think that there might be
a problem.

Note that in the case of PulseAudio, 5.0-3 (in Jessie) removes the
initscript entirely.

This reverts commit cac0d797.

This reverts commit c7c34bb7.

Conflicts:
	config/chroot_local-hooks/52-update-rc.d

The control port filter will be started as the vidalia user,
as the permissions it requires matches well with that of
the vidalia user.

It is always started, and does never need to be restarted.
If Tor is not running when a newnym request is made, it will
just return back an error message.

i2p is currently not installed on Wheezy-based Tails.

The ticket says to leave Bluetooth alone, but if we do that and it's disabled by
default by the firmware or whatever, then it would have no chance to get
connected devices, and then the design we decided for
todo/protect_against_external_bus_memory_forensics could not be implemented for
this protocol. So, we unblock it.

It has been orphaned in Debian, has quite some bugs in there, and apparently
Tor's DNSPort's own caching could be good enough.

This reverts commit 34daa6f0.

Conflicts:
	config/chroot_local-hooks/52-update-rc.d
	config/chroot_local-includes/etc/default/kexec
	config/chroot_local-includes/etc/init.d/tails-reconfigure-kexec
	config/chroot_local-includes/etc/init.d/tails-sdmem-on-media-removal

Tails shutdown sequence should be as fast as possible. So it is better to skip
initscripts that are not relevant to our amnesic environment.

See <https://mailman.boum.org/pipermail/tails-dev/2012-May/001180.html> for the
relevant discussion.

Calling update-rc.d manually is quite error prone: for example, 'ttdnsd' is
actually required to be started after 'tor', but this was not reflected in the
number sequence.

Instead, we now patch the initscripts and rely on insserv to figure out the
correct ordering for the startup and shutdown sequence.

The patch to kexec-load is adjusted for consistency.

What we don't want is that i2p starts on boot, rather than never running its
initscript (e.g. on shutdown).

Numbering initscript sequence is difficult and error prone. Let's just rely on
the fact that we have dependency based boot sequencing available now!

Given we provide a proper Required-Stop header, we can leave the halt and
reboot initscript in place. They will never be called as long as `tails-kexec`
succeed. If it don't, then it still provides a better user experience to
shutdown or reboot the machine than to leave the computer hanged.

memlockd keeps our tails-kexec file in memory. This is crucial to have
emergency shutdown on media removal. So in order to prevent any race
condition regarding the avaibility of the files needed to start the
memory wiping kernel, we do everything we can to prevent memlockd from
being unloaded during shutdown. Namely:

 1. We properly remove stop symlinks to the memlockd initscript using
    `update-rc.d`.
 2. We add memlockd PID to the process that are ommited by the sendsigs
    script (responsible for sending TERM and KILL signals to remaining
    processes).
 3. Do not require that memlockd be stopped before stopping
    tails-sdmem-on-media-removal.

In addition, we fix initscript ordering related to
tails-sdmem-on-media-removal.

These changes towards memlockd are too specific to Tails' needs to be
upstreamed: if memlockd is used to keep files in memory from rw media,
having memlockd running would prevent proper unmounting. That would be
bad.

Ensure that all local hooks start with 'set -e'. This should prevent errors
to slip through the build process.

Some Tails NM hooks need the user to be logged in to run properly.
That's why tails-greeter starts NetworkManager at PostLogin time.

gdomap is not used between processes running as the same user on the same host.

Avoid breaking the build by adding too much scripting to /etc/default/kexec,
that is sourced by the kexec-tools.config maintainer script.

Since we don't ship those in /boot anymore, the symlinks in / are broken.
Moreover, once we ship several pairs of kernel/initrd, the running pair
must be cached (and is already used by our kexec configuration).

It hides the explanation and warning about sdmem we want to display.

plymouth.postinst creates links using update-rc.d, so the links it creates
cannot be disabled using LSB headers.

We only want hdparm so that laptop-mode-tools can use it.

- build initramfs with sdmem support
- install kexec-tools that are used to run the sdmem-enabled initramfs on
  shutdown
- pass the rebooting/halting status to the kexec'd initramfs using a custom
  /etc/default/kexec
- remove custom live-boot packages to disable previous (buggy and incomplete)
  sdmem implementation
- provide our own tails-kexec initscript to replace /etc/init.d/kexec:
  tails-kexec is more post-eject-time friendly and informs the user s/he can
  remove the boot device before the sdmem process before it happens; hence
  switching live-boot boot parameter to noprompt
- kexec-load, tails-kexec-cache and tails-kexec are run on halt as well as on
  reboot; to achieve this we need to patch the kexec-load initscript LSB header:
  update-rc.d is not enough as insserv uses LSB headers rather than update-rc.d
  arguments
- don't disable init concurrency at shutdown anymore: the initscripts
  dependencies now are be accurate enough to prevent running in
  parallel scripts that should be run sequentially

Dependency based boot sequencing is now the default in Debian.

We want to benefit from it to decrease boot time,
but we need to disable it for the shutdown sequence in order to have our memory
wiping hooks working in a reliable way... or at least to help fixing their bugs.