Architecture

Apertis is primarily built from Debian source packages utilising optimised, automated workflows based on the processes used by Debian. The Debian sources were selected due to their high quality and modularity, them having no reliance on a single vendor and the large number of components already packaged. Apertis utilises the tools provided by the Debian community, combining these with other tools, such as GitLab and the Open Build Server (OBS) to create a more automated, optimised workflow. [Read More]

Apertis is a versatile open source distribution and associated infrastructure, originally tailored to automotive use cases, but which has grown to be a fit for a wide variety of electronic devices. While Apertis provides components both for deployment on target devices and to meet the needs of development workflows, these are clearly separated, with special care taken to ensure that components intended for deliverables are free from problematic licensing constraints. [Read More]

The Apertis infrastructure is itself a fundamental component of what Apertis delivers: its goal is to enable developers and product teams to work and collaborate efficiently, focusing on their value-add rather than starting from scratch. This document focuses on the components of the current infrastructure and their monitoring and testing requirements. The Apertis infrastructure The Apertis infrastructure is composed by a few high level components: GitLab OBS APT repository Artifacts hosting LAVA From the point of view of developers and product teams, GitLab is the main interface to Apertis. [Read More]

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]

Background One of the main goals for Apertis is to provide teams the tools to support their products for long life cycles 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 leading-edge functionality and stability. [Read More]

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]

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]

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]

Build infrastructure on Intel x86-64 Introduction The current Apertis infrastructure is largely made of hosts based on the Intel x86-64 architecture, often using virtualized machines. The only exceptions are: OBS workers used to build packages natively for the ARM 32 bit and ARM 64 bit architectures LAVA workers, which match the reference hardware platforms While LAVA workers are by nature meant to be hosted separately from the rest of the infrastructure and are handled via geographically distributed LAVA dispatchers, the constraint on the OBS workers is problematic for adopters that want to host downstream Apertis infrastructure. [Read More]