-
Notifications
You must be signed in to change notification settings - Fork 89
Bill of Materials
This page attempts to track the core dependencies, their level of coupling (necessary to build = high, optional = low), linking method (static, dynamic) along with licensing and security implications.
Component:
On a high level, Arcan is split into a core engine, its os integration platforms, a set of de-coupled services and protocol bridges as well as an IPC system (SHMIF) to tie these together. The coupling for integration platforms refers to when the specific platform path is chosen/built.
Engine (src/engine):
The engine is split into a user scripting layer, a core and a platform layer for system integration ("event"), one for graphics (drawing) one for video (display control), and one for audio. The selection of these are determined statically at build-time, where the selection is coupled into a tagged build (e.g. arcan-version-lua-audio-video) that is part of crash dumps and other user reporting forms.
| Name | Linking | Coupling | License | Notes |
|---|---|---|---|---|
| Core | N/A | N/A | 3-BSD | |
| ALT (engine-Lua API) | S | High | GPLv2 | |
| Lua51 OR LuaJit2.x | S / D | High | MIT | |
| STB (image formats) | S | High | CC0 | To be migrated to decode for security reasons. |
| Freetype, Harfbuzz | D | High | FTL/oMIT | (FTL = BSD + attribution) oMIT ("old" MIT) |
| Sqlite3 | S / D | High | PD |
Graphics (src/platform/agp):
The graphics platform is referred to as 'AGP' and provides 2D/3D rendering matched to about the hardware capabilities of embedded devices around 2013 as the lower bound in order to reach the widest reasonable audience. The intent is to expand these with a 'document format' based renderer as well as a software dedicated one to reach more devices.
| Name | Linking | Coupling | License | Notes |
|---|---|---|---|---|
| GL21,GLES3 (MESA) | D | High | MIT |
Audio (src/platform/audio):
The audio layer has recently been broken out of the core engine as a step towards swapping it out for simpler and more permissible licenses. The current implementation relies on openAL-Soft due to its role in portable 3D audio (HRTFs) for intended VR applications. Where such are not needed, simpler options are being evaluated.
| Name | Linking | Coupling | License | Notes |
|---|---|---|---|---|
| openal: OpenAL-soft | D | High | LGPL |
Video (src/platform/sdl2,egl-dri):
The video platform deals with negotiating optimal formats and timing parameters with the graphics rendering code. It is responsible for integration with an outer display server or native graphics drivers, depending on user preferences.
| Name | Linking | Coupling | License | Notes |
|---|---|---|---|---|
| egl-dri: gbm/kms | D | High | MIT | |
| egl-dri: libbacklight | S | Low | MIT | |
| sdl2: sdl2 | D | High | Zlib |
Event (src/platform/sdl2,evdev,wscons): The event platform deals with input sources, sensors and low intensity output devices (LED indicators, backlight).
| Name | Linking | Coupling | License | Notes |
|---|---|---|---|---|
| sdl2: sdl2 | D | High | Zlib |
SHMIF
The IPC system relies exclusively on OS(POSIX) based primitives and has no explicit other external dependencies. There is an extended form, arcan-shmif-ext for accelerated passing of hardware graphics resources, which follows GBM/KMS/Mesa (MIT) license.
The protocol implementation (src/a12) and the support tool for client/server connection discovery and management.
| Name | Linking | Coupling | License | Notes |
|---|---|---|---|---|
| zstd | S | High | BSD | |
| blake3 | S | High | CC0 | (dual-license, Apache license) |
| chacha(8,20) | S | High | MIT | vendored implementation chosen for ease of use, assumed to be swapped for stronger verified |
| x25519 (monocypher) | S | High | CC0 | Chosen over more popular nacl/libsodium due to size / simplicity |
| ffmpeg | D | Low | GPL* | Actual license depends on os / distribution provided, for higher security delegate to decode frameserver or passthrough to any other shmif capable application. |
Decode (src/frameserver/decode/default):
The role of the decode frameserver is to provide a least privilege form of parsing of primarily media formats. Other components can and do delegate their media decode processing to this process. The default build act as a dependency / license sponge where are all build time optional, the coupling is low and all act as a separate program. As such the implementation itself can be swapped out or stubbed out with clear consequence (loss of performant formats to cover license concerns or gain of new ones) without changing the rest of the system. This decoupling/security intention applies to the other frameservers (encode, remoting, net) as well.
| Name | Linking | Coupling | License | Notes |
|---|---|---|---|---|
| libvlc | D | Low | LGPL2.1 | |
| espeak | D | Low | Apache | |
| mupdf | D | Low | AGPL | |
| uvc | D/S | Low | BSD | |
| nanosvg | S | Low | Zlib | |
| stb | S | Low | Zlib | |
| tinyobj | S | Low | MIT |
Encode:
The encode frameserver is the counterpart to decode and perform human-to-non-human transformations that are lossy and only partially reversible. It is also used for scrubbing or tampering with privacy affecting metadata. Its decoupling and security intentions are the same as for Decode.
| Name | Linking | Coupling | License | Notes |
|---|---|---|---|---|
| FFMPEG | D | High | GPL* | GPL license version will vary with OS/distribution packaging |
| Libvncserver | D | Low | GPLv2 | |
| Tesseract | D | Low | Apache |
Remoting:
The remoting frameserver is a simplified "specifically used for accessing shared remote desktops" which is mainly a different sandboxing profile than for other clients given its "only networking" use.
| Name | Linking | Coupling | License | Notes |
|---|---|---|---|---|
| A12 | S | High | BSD | |
| libvncclient | D | Low | GPL |
The net frameserver act as an engine to arcan-net/a12 implementation bridge with presets for making it easier to use from Arcan Lua scripts. Its bom/dependencies are thus the same as for A12.