pEp Installer for Linux (Binary)

About

This is the pEp Thunderbird installer for Linux. This tool installs binaries provided by pEp, it is unrelated to packaging provided by Linux distributions.

This reopsitory contains multiple components:

• The shell scripts that perform the installation.
• A GUI program that uses these scripts and guitds the user.
• A launcher mechanism to run this program on double-click in most desktop environments.
• Build scripts to compile all required pEp software into portable binaries.
• Build scripts to compile the installer program into portable binaries.
• Build scripts to create the installer bundle.
• CI configuration to run those build steps automatically.

This project depends on the following other projects:

• pEpEngine, libpEpAdapter, pEpJSONAdapter, sequoia, libetpan: For the actual pEp implementation.
• The pEp Thunderbird addon.
• The ImportFromEnigmail script for key import and parts of the installation.
• Python 2.7 for this script, compiled as a static executable.
• wxWidgets (with X11 backend) for the GUI.
• Some more C++ libraries for the installer.
• Alpine Linux as a build platform for statically linked binaries.

Build

See parts/build for a collection of small script snippets to build all dependencies and the installer intself. See documentation there.

The CI simply invokes these scripts in Docker containers; for local builds, the scripts can also be run manually, potentially using a chroot environement.

Run

Running install.run from the unpacked bundle should start the installer.

install.run is a statically linked binary executable, which is executed by default by most Linux desktop environments.

This program then launches .Setup/tb_setup, which is the actual installer.

tb_setup takes a number number of command-line arguments to adjust the installation, see ./tb_setup -h.

Features

The ./tb_setup binary is meant to be wrapped by a *.desktop file carrying specific parameters for the installation.

Whenever tb_setup is launched this way, it will parse the .desktop file and extract installation parameters. It will then set defaults and launch install scripts according to the parameters.

[Desktop Entry]
X-pEp-Exec=
X-pEp-Import-Exec=
X-pEp-MDA-Version=
X-pEp-MDA-Platform=
X-pEp-MDA-OS=
X-pEp-MDA-Variant=
X-pEp-Prefer-User-Install=yes|1|no|0

The options and values are case sensitive.

The X-pEp-Exec is a file path to the script performing the adapter installation. It is called with the command line arguments and with appropriate privileges (root or user) as described below. The X-pEp-Import-Exec is called after the adapter installation, and called with the command line argumentsas described below, while it is always called as the current user. The values of X-pEp-MDA-Version, X-pEp-MDA-Platform, X-pEp-MDA-OS and X-pEp-MDA-Variant are passed through to the install scripts.

If not set explicitely, X-pEp-MDA-Variant defaults to tb for system installs, and tbmini for user installs.

To enable the uninstall option, launch tb_setup with the -U argument.

Note: Not all of these options are currently fully implemented.

For the install.run launcher, the .desktop file is passed as a command line argument.

Screenshots

These will always be out of date, but give you an idea.

- -

Translation

The installed can be localized. To extract strings, run make update-po, then commit changes to the repository. The translation can then be done in weblate here: https://translate.pep.security/projects/pep-software/pep4thunderbird-linux/

Versions

Most dependencies are handled as git submodules.

After checkout, do git submodule init; git submodule update to download the code. To update such a dependency, cd to the right place in contrib/, and git checkout whatever version you like; then git commit -a in the project root. Use git submodule to display the currently used versions.

Some dependencies are not imported as submodules, and have their version number set in parts/build/settings.sh. The version numbers can be updated there. These generally don't need to be updated very often.

Many dependencies (incl. nettle, hogweed and gmp for the actual crypto code) come from Alpine Linux. Since we use the edge branch of Alpine, these are generally updated very often, but also we have no control over their verision numbers. The versions used are reported in the CI output.

The installer itself also has a version number, which is used in some places. This version number should be tagged in this repo. It is generally not meant for public use, as the TB Linux releases are supposed to be identified by the Addon version number.

CI

A big part of this repo is about actually creating a binary package that works across Linux distributions.

In the CI, this process is split into two steps:

• The build-image step creates a Docker container with a fresh Alpine Linux setup, installs all system dependencies (incl. many static libraries) and then builds sequoia, engine, adapter, and wxWidgets incl. some dependencies.
• The installer step uses the latest Docker image from the previous step, and uses this platfrom to build the C++ parts of the installer, package the Addon, and bundle everything into a zip file, that is then uploaded. The statically linked Python 2.7 is downloaded from a web server.

The build-image step is automatically run on any push to a build-image/* branch and can easily take 1h. The installer step is much faster (<5min) and is automatically run for every branch update and merge request.

To update sequoia, engine, adapter or wx, push a branch with the changes to the build-image/ folder, then wait for the build. Once it is done, merge the branch into master to trigger a installer build. The build-image/ branch can be deleted.

The output of the CI is publicly visible in https://depot.pep.security/thunderbird/tb-linux-installer/ . The docker registry used for the build-image step is not available to the outside.

There are multiple things wrong with this setup, but this is how it works today.