Encrypted updates

The encryption of the update file makes accessing its contents more difficult for bystanders, but doesn't necessarily protect from more resourceful attackers that can extract the decryption key from the user-owned device. The bundle encryption is done using the loop device with standard/proven kernel facilities for de/encryption (e.g. dm-crypt/LUKS). This allows the mechanism to be system agnostic (not tied to OSTree bundles), and can be used to ship updates to multiple components at once by including multiple files in the bundle. [Read More]

Long term reproducibility

Background One of the main goals for Apertis is to provide teams the tools to support their products for long lifecycles needed in many industries, from civil infrastructure to automotive. This document discusses some of the challenges related to long-term support and how Apertis addresses them, with particular interest in reliably reproducing builds over a long time span. Apertis addresses that need by providing stable release channels as a platform for products with a clear trade-off between updateness and stability. [Read More]

Canterbury legacy application framework

Apertis currently ships with a custom application framework based on the Canterbury app manager which is in the process of being phased out in favor of upstream components like Flatpak, see the application framework document for more details. Flatpak and Canterbury cover the core tasks of an application framework: packaging distribution sandboxing When Canterbury was designed Flatpak didn't exist and the available technologies were quite different from what is in today's usage, so it's now time to reconsider our approach. [Read More]


It is important to properly version software to enable software changes and compatibility of components to be tracked, as well as to aid with bug tracking and the application of updates. To achieve this, it is important that we effectively version each source component, binary package and release. The approach to versioning depends on the entity being versioned and in the case of source code whether it is developed specifically for Apertis or an existing project used by Apertis. [Read More]

Apertis secure boot

For both privacy and security reasons it is important for modern devices to ensure that the software running on the device hasn't been tampered with. In particular any tampering with software early in the boot sequence will be hard to detect later while having a big amount of control over the system. To solve this issues various vendors and consortiums have created technologies to combat this, known under names as “secure boot”, “highly assured boot” (NXP), “verified boot” (Google Android/ChromeOS). [Read More]

The case for moving to Debian stretch or Ubuntu 18.04

This document provides the analysis and rationale for migrating to Debian as the projects upstream distribution. This change was completed in late-2018 and as such all releases since v2019 have been based on Debian. Why was Apertis based on the Debian/Ubuntu ecosystem At the beginning of Apertis, a few platforms were considered for the base of Apertis: MeeGo, Tizen, OpenEmbedded Core, Debian and Ubuntu. A choice of Debian/Ubuntu ecosystem was based on Debian being ‘one of the oldest and largest (most inclusive of OSS packages), and one of the first Linux distributions to feature an ARM port’, providing ‘a very solid distribution baseline’ and ‘a high degree of robustness against the involvement or not of individual contributing companies’, while Ubuntu bases on Debian but adds value important for Apertis (see below). [Read More]


These are some of the slides and presentations which members of the Apertis community have previously shared (ordered newest to oldest): 2019 Building an entire Debian derivative from Git The Apertis approach to using git as part of the build pipeline by Andrej Shadura 2018 Testing your distribution with LAVA Introducton to testing with LAVA by Andrej Shadura and Guillaume Tucker 2017 Managing build infrastructure for a Debian derivative [Read More]

API Stability

Summary Define API stability guarantees for your project (Stability) Ensure version numbers are changed as appropriate when API changes (Versioning) API and ABI At a high level, an API – Application Programming Interface – is the boundary between two components when developing against them. It is closely related to an ABI – Application Binary Interface – which is the boundary at runtime. It defines the possible ways in which other components can interact with a component. [Read More]

Debug Symbol Packages

Packages automatically generate debug symbol packages at build time, the packages have the package name extension -dbgsym. Infrastructure To be able to benefit from dbgsym packages, the infrastructure must be ready for them, the requirements are: reprepro: must support dbgsym since 4.17.0 debhelper: with dbgsym support since 9.20160114 dpkg-dev: support for dbgsym since 1.18.2~ When building packages with those tools, automatic debug symbols will be generated for all built packages. [Read More]

Boot Process

Apertis has a fairly typical Linux boot process: A platform specific bootloader performs initial low-level configuration of the system The Linux kernel performs higher level configuration and creates a standardised environment The kernel passes execution to the user space which enables services based on the functionality provided by the kernel and sets up the system to accept user input Critical sequences during startup The phases during startup generally proceed from most- to least-critical. [Read More]