Architecture

Apertis is a versatile open source infrastructure tailored to the automotive needs and fit for a wide variety of electronic devices. Security and modularity are two of its primary strengths. Apertis provides a feature-rich framework for add-on software and resilient upgrade capabilities. Beyond an operating system, it offers new APIs, tools and cloud services. Apertis is not just a Debian-derived GNU/Linux distribution. It comprises: code hosting; code review tools; package build and image generation services; and an automated testing infrastructure with the aim of providing a clean, reliable environment. [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]

Sysroots and devroots are two development rootfs meant to provide an environment to build software for Apertis, targeting foreign architecture that don't match the CPU architecture of the build host (for instance, building ARM64 binaries from a Intel-based host). They are meant to address different use cases with different trade-offs. Sysroot Sysroots are file system trees specifically meant for cross-compilation and remote debugging targeting a specific release image. They are meant to be read-only and target a specific release image, shipping all the development headers and debug symbols for the libraries in the release image. [Read More]

Apertis provides the GTK port of WebKit as its web engine. To ensure low maintenance effort, no changes are made to the downstream branch, any improvements should go to the upstream project. Security maintenance Like all other major browser engines, the GTK port does not provide long term support, so security maintenance comes down to staying up to date. The general approach Apertis takes is to follow whatever Debian provides. The project may also importing a new upstream release that has not been made available in Debian yet if an important fix is available. [Read More]