The concept designs are a set of technical documents covering many aspects of the project, written through the history of the project, taking into account the status of the project at that time. These documents cover topics that have been researched but not necessarily implemented in Apertis at the time of writing.

Information in these documents may be outdated, but nonetheless provide important context for the decision making process and overall vision of the project.

Test Case Review

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]

License-compliant TLS stack for Apertis targets

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]

Automated License Compliance

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]

Integration of OP-TEE in Apertis

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]

The next-gen Apertis application framework

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]

Test case dependencies on immutable rootfs

Test case dependencies on immutable rootfs Overview Immutable root filesystems have several security and maintainability advantages, and avoiding changes to them increases the value of testing as the system under test would closely match the production setup. This is fundamental for setups that don't have the ability to install packages at runtime, like OSTree-based deployments, but it's largely beneficial for package based setups as well. To achieve that, tests should then ship their own dependencies in a self-contained way and not rely on package installation at runtime. [Read More]

Web Runtime

Definitions web runtime a set of rules, supporting libraries, App Framework and SDK integration to allow development and integration of web and hybrid apps targeting the Apertis system web app an application using web technologies such as HTML, CSS and JavaScript, integrated on the system through the web runtime native app an application targeting the Apertis system using the Apertis UI toolkit for its user interface, developed in either C or one of the other supported languages such as JavaScript hybrid app a native app that includes a web page as a piece of its user interface; it may use the web runtime infrastructure but not necessarily does Overview The web runtime will be provided through a library that mediates the interaction between the WebView and the system, and a launcher. [Read More]

Compositor security

The compositor is the component of Apertis that is responsible for drawing application windows and other graphical elements on the screen. Background The compositor is a process responsible for combining surfaces (texture buffers) representing application windows into the single 2D image displayed on the screen. In an X11 environment, it combines the roles of a window manager and a compositing manager. In a Wayland environment, it also takes on the role of the display server from X11. [Read More]

Egress filtering

This way to the egress! — attributed to P. T. Barnum An application that handles confidential data might have a security vulnerability that leads to it becoming controlled by an attacker. This design aims to mitigate such attacks. Assumptions We assume that the user has some confidential data (for example the contents of their address book), accessible to a particular application bundle, and that an attacker's goal is to gain access to that confidential data. [Read More]

Content hand-over

Content handover is when an application is asked by the user to open a file it doesn't know how to handle or to start a service it is not responsible for providing. For example, a browser just finished downloading an epub file and the user now wants to open it. The browser will ask the system to start the application responsible for dealing with that file. Another example would be a map application in which the user located a destination and now wants to navigate. [Read More]