Concept Designs

Overview The intention of this document is to outline the Apertis technical direction and vision for the Apertis platform as it would be used on a device, container or VM. This document does not cover the overall Apertis infrastructure and its general principles around for example open source license expectations, image building and the release process. These topics are covered in their own respective documents. Apertis is, by design, a very flexible platform to build on. [Read More]

Introduction As interest and use of Apertis grows it is becoming increasingly important to show the health of the Apertis infrastructure. This enables users to proactively discover the health of the resources provided by Apertis and determine if any issues they may be having are due to Apertis or their infrastructure. Terminology and concepts Hosted: Service provided by an external provider that can typically be accessed over the internet. Self-hosted: Service installed and run from computing resources directly owned by the user. [Read More]

Introduction In accordance to its Open Source License Expectations, Apertis currently ships a very old version of GnuPG which is still released under the GPL-2.0 terms, before the upstream project switched to GPL-3.0. This is problematic in the long term: the purpose of this document is to investigate alternative implementations with licensing conditions that are suitable for Apertis target devices. The use cases for Apertis target images only depend on GnuPG for verification purposes, not for signing or encrypting. [Read More]

Introduction The Apertis project has been experimenting with the use of Eclipse hawkBit as a mechanism for the deployment of system updates and applications to target devices in the field. The current emphasis is being placed on system updates, though hawkBit can also be used to address different software distribution use cases such as to distribute system software, updates and even apps from an app store. Apertis has recently deployed a hawkBit instance into which the image build pipelines are uploading builds. [Read More]

Due to the nature of Apertis and its target markets there are licensing terms that are problematic and that forces the project to look for alternatives packages. The coreutils package is good example of this situation as its license changed to GPLv3 and as result Apertis cannot provide it in the target repositories and images. The current solution of shipping an old version which precedes the license change is not tenable in the long term, as there are no upgrades with bugfixes or new features for such important package. [Read More]

Apertis has a slowly growing number of test cases that have been written over the years that the Apertis project has been running. Effort has been made to automate many of these tests, however many still remain as manually run testing scenarios. Due to limited testing bandwidth, many of these manual tests are not frequently performed. Additionally there may be automated tests that are being run that, due to changes in the focus and direction of the Apertis project since it’s inception, are no longer particularly useful. [Read More]

The Apertis distribution provides both a development environment for electronic devices as well as a software stack to be used on them. In line with this goal, the Apertis project strives to provide software components that, where there is intent that they form part of the software stack on the devices themselves, are free from licensing constraints that may make it unsuitable in certain use cases. An example is software licensed under the terms of the GNU GPL-3 (General Public License) or LGPL-3 (Lesser General Public License) which are known to present a problem as they sometimes conflict with regulatory requirements and thus Apertis will take measures to avoid such packages being provided as part of the “target” package repositories. [Read More]

A Linux system such as those assembled by Apertis contain components licensed under many different licenses. These various licenses impose different conditions and it is important to understand to a good degree of fidelity the terms under which each component is provided. We are proposing to implement an automated process to generate software Bills Of Materials (BOMs) which detail both the components used in Apertis and the licensing that applies to them. [Read More]

Some projects that wish to use Apertis have a requirement for strong security measures to be available in order to implement key system level functionality. A typical use case is enabling the decryption of protected content in such a way that doesn’t allow the owner of the device doing the decryption to access the decryption keys. Another use for strong security is the protection of authentication keys. By shielding such keys within these strong security measures, it becomes much harder for the keys to be stolen and be used to impersonate the legitimate user. [Read More]

As a platform, Apertis needs a vibrant ecosystem to thrive, and one of the foundations of such ecosystem is being friendly to application developers and product teams. Product teams and application developers are more likely to choose Apertis if it offers flows for building, shipping, and updating applications that are convenient, cheap, and that require low maintenance. To reach that goal, a key guideline is to closely align to upstream solutions that address those needs and integrate them into Apertis, to provide to application authors a framework that is made of proven, stable, complete, and well documented components. [Read More]