This section provides documentation covering the implementation goals and strategies taken to enable features or functionality in Apertis.

For more detailed guidance on implementing or using specific functionality, please refer to the guides.

Change History

Whenever daily builds of Apertis images are run, a set of changes from the release’s previous daily images is saved as a JSON file to https://images.apertis.org/daily/RELEASE/BUILD/meta/changes-since-PREVIOUS.json. Format The format of the changes JSON file is: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 { // Array array of images and their changes. [Read More]

License Scanning

The license is an important element in open source projects as the license define acceptable use cases, user rights, and contribution guidelines. There are different ways to identify the license from the project source code such as SPDX headers, the LICENSE file, and the COPYING file. However an open source project may contain files from other projects and may use different licenses for different files. Apertis has certain licensing expectations. In order to improve the accuracy of the licensing information, Apertis performs license scanning as part of it’s continuous integration process [Read More]

The Apertis Workflow

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]

The Apertis Platform

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]

Infrastructure monitoring and testing

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]

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 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]

Canterbury legacy application framework

The custom application framework based on the Canterbury app manager has been removed from v2022dev2 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]

Versioning

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]