GitLab

cp + rm == mv in this case. Also let's make that section separate from
the "Remove unwanted" one since it does something else. It's important
that we first clean it up from the unwanted Wikipedia plugin from the
Tor Browser.

This will make the generation deterministic, which is important for a
smaller IUK delta, and reproducible builds. Inspired by patch provided
on Debian bug #783933.

The new (ESR38) search bar only shows icons, which is problematic when
we want to include several locales of some search engine at the same
time, like Wikipedia (we want to include English in non-English
locales). Now we also generate localized Wikipedia search engine
plugin icons, which has an indicator of which language is used (by
language code) which should mitigate this.

Will-fix: #9955

It was introduced (#9381) for reasons that ended up being wrong (#9594).

Here, we also remove amd64 APT sources and dpkg's support for amd64 as a foreign
architecture. We'll need them again when we want to ship Linux 4.x, but once
we're there we can perhaps enable amd64 sources only for selected APT
repositories, to avoid re-introducing #9381.

Reverts:
e9d2e345
181c6d26
e1d331aa

Will-fix: #9748

These profiles come from the apparmor-profiles package, and we don't ship the
corresponding executables. The goal here is to avoid increasing boot time.
Note that they are installed in complain mode by default anyway.

Will-fix: #9757

Not only this introduces needless variations between ISO images built from the
same source (hence blocks deterministic builds), but there's a risk that some
package (either one we already ship, or one that we ship some day, or one that
users install themselves) actually use this pair of SSL keys on the Internet,
which is wrong since the private key material is public.

Note that:

 * We run update-ca-certificates after deleting the snakeoil SSL certificate,
   to ensure it's not included in /etc/ssl/certs/ca-certificates.crt.
 * We make sure we delete all symlinks pointing to the SSL snakeoil certificate
   or key, because it avoids having to understand what symlinks are created
   on current Debian, and to track any future changes in this area.

Will-fix: #9416

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

Previously these parts have been spread out in several, heavily
coupled hooks and static configurations, making it very hard to get an
overview of how it all actually works. Now we instead do everything in
one place, and generate things programatically as much as possible,
which makes supporting another locale much simpler (just adding a
single line with a few pieces of needed info!). Consequently this
commit also adds better localization for every locale supported by the
Tor Browser (added: ar, es, fa, ko, nl, pl, ru, tr, vi and zh_CN)
instead of the euro-centric (w.r.t. actually adding localization) ones
we had picked before. Also, we'll get build level errors for many
types of errors, so they're caugt early.

This commit may seem like a gigantic, non-atomic beast, but splitting
it would be hard, and it actually mostly removes stuff. Its design is
simple: We have a description file that, for each supported Tor
Browser locale, has the extra pieces of info needed, like the
localized name of the language, the parameters needed for certain
search engines etc. Then we apply them to:

* a templates for the amnesia branding locale file, and put in the
  relevant values there so the default search engine is selected, the
  correct spellchecker (if installed) is pre-selected, and our
  homepage is localized (if supported).

* a template for each of the search engines we want to localize
  (currently Start Page and Disconnect.me -- we could do Google but
  most (all?) locales get a localized one from the Iceweasel
  localization packages) and generate localized ones.

Also, following the Tor Browser's recent switch, we now use
Disconnect.me as the default search engine, although we localize it
for each supported locale.

Will-fix: #9309

Our installation script determines the Tor Browser version from the
tarball filenames and then looks in "$(cat
tbb-dist-url.txt)/$VERSION", which isn't very flexible. For instance,
for the pre-release of Tor Browser 4.5 our script looks in:

    http://people.torproject.org/~mikeperry/builds/4.5/

when they in fact were stored in

    http://people.torproject.org/~mikeperry/builds/4.5-build5/

So let's just store the full URL to the directory storing the
tarballs.

As of Torbutton 1.9.1.0 our extensions.torbutton.test_enabled pref is
part of upstream, so we don't have to maintain our custom .deb any
more! Note that we still patch our custom Torbutton with
0001-restore-status-panel-on-ff4.patch (inherited from Debian's
packaging) but it seems irrelevant for Tails.

Without the -t option, which makes syndaemon only disable tapping and
scrolling and not mouse movements, florence is unusable when syndaemon
is running. In Wheezy, GNOME invokes syndaemon without -t, and the
option it passes are hardcoded, so we're forced to do this ugly
workaround, which luckily can be removed once we're based on Jessie
since -t is passed then. For details, see #9011.

Since Tor 0.2.6.x our custom patches for the ClientTransportPlugin
hacks are not needed any more. Now we can set ClientTransportPlugin
for the relevant transports in torrc without it causing problems with
any of the various *Proxy options. So let's do that!

Will-fix: #7283

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

Commit c47f5dd6 adjusted some indentation, but didn't do it everywhere it was
needed, which lead to inconsistencies.

Patch from https://labs.riseup.net/code/issues/8724#note-12 with some whitespace fixes.

It's automatically installed earlier by tasksel, since it has Priority:
standard, so removing it from our wanted packages list is not enough to get rid
of it.

Running Tor Launcher with the same AppArmor profile as Tor Browser would force
us to open that profile too broadly. E.g. it requires the ability to run
dbus-daemon, to give an idea.

Given:

 * Tor Launcher runs as a dedicated user
 * Tor Launcher runs very early, at a time when the user likely isn't doing
   anything sensitive to X keystrokes sniffing etc., and closes immediately
   after Tor is ready
 * Tor Launcher offers a very limited set of functionality

=> it seems safe enough to run it unconfined, at least for now.

This leaves us more time to resolve merge conflicts when needed.

live-build expects to be the only one that manages APT sources.
Since feature/8194-APT-socks was merged, we're breaking this assumption of its,
by mangling APT sources under live-build's feet via chroot_local-hooks.

More specifically, if:

 * $LB_MIRROR_CHROOT != $LB_MIRROR_BINARY or
   $LB_MIRROR_CHROOT_SECURITY != $LB_MIRROR_BINARY_SECURITY,
   as is the case when building with Vagrant or when following our manual
   build setup instructions accurately (live-build defaults to
   ftp.de.debian.org for some of its APT configuration),

or:

 * one has dropped .deb's in config/chroot_local-packages, as contributors
   without write access to our APT repository may want to do,

then after completing the chroot_local-hooks stage, lb_chroot_sources would
rewrite APT sources to match what we have previously configured (see the check
at lines 490-498 in live-build 2.x tree), and therefore the ISO image would have
http:// URLs configured instead of the expected tor+http://.

Therefore, let's mangle APT sources configuration at boot time instead.

Give the CA bundle for authenticating our website a more generic name, and adjust the info message accordingly.

We'll soon be using the same bundle at least for the security check code too.

Our website's certificate transition is over, and the current certificate
is signed by another CA.

This bundle contains both the CA that signed the current certificate,
and the one that will sign the next one.

See Debian bug #714932.