Security Overview


This is an overview of some of the security features of the Open Runnable Bundle file format.

Some of these features require the installation of ORB Launcher.

If you have any ideas, suggestions or criticism, feel free to send us a message.

Secure distribution

Status: Implemented

The green “padlock icon” in Firefox, indicating a secure HTTPS connection

All software is distributed via a secure and encrypted HTTPS connection, thanks to a Let’s Encrypt certificate.

DNSSEC is also enabled on this website. In simple terms, it makes it harder for someone to “fool” your computer into visiting a fake/malicious website pretending to be the real Orbital Apps.

We are also considering enabling HSTS (HTTP Strict Transport Security) and adding the website to the HSTS preload list.

Script-based software

Status: Implemented

We deliberately choose to write our software in a scripting language (bash) because we strongly believe this greatly increases the transparency, and, indirectly the security and verifiability of the software.

Only launch files with the .orb extension

Status: Implemented

By design, ORB Launcher is only “activated” for files with the .orb extension

Always show the file extension

Status: Implemented

It is not possible to hide the extension of an executable file like in Microsoft Windows ( picture.jpg.exe showing as picture.jpg )

This means a file named picture.jpg.orb will always be shown as picture.jpg.orb

Main ORB icon always shown

Status: Implemented

The “blue ORB” is always shown

By design, all ORB files, even signed ones, show the custom app logo on the corner of the main ORB logo.

This makes it harder for malicious files to disguise themselves as a PDF or other types of documents

Easy to inspect ORB files

Status: Implemented

By design, all ORB files are easy to open and inspect.

In practice, ORB files can be mounted with “Disk Image Mounter”

If the ORB contains a compressed filesystem (app.squashfs), that can also be opened with “Disk Image Mounter”

Integrity checking

Status: Implemented

All ORB Apps undergo a “basic check” to ensure they are not damaged.

In the future, we are considering doing an extensive check based on SHA512 hashes and cryptographic signatures.

Signed ORB files

Status: Implemented

All ORB files are signed with PGP, using a 4096 bits key (the .asc files are the signatures)

Signed ORB contents

Status: Implemented

The contents of the ORB (in reality, an ISO) contain a SHA512SUM file (which is the file that contains all the SHA512 hashes of all files inside that ISO).

The SHA512SUM file is cryptographically signed with PGP, using a 4096 bits key.

Always expire sudo password

Status: Implemented

Before running any application, the sudo password is removed from the cache, with the command:
sudo -k.

This prevents ALL applications from automatically gaining root without first asking the user for the permission.

Monthly releases

Status: Implemented

We are currently doing monthly releases of Superdebs and ORB Portable Apps.

The new releases are expected to be made available in the first half of each month, and will be announced in the official blog.

This means apps will be re-created with all the new security updates and (possibly) bug-fixes.

Note: Installing a Superdeb is, from a technical point-of-view, exactly the same as installing the software from the repositories. As such, any App installed via a Superdeb will receive updates via the normal Ubuntu update mechanism.

No forced updates

Status: Implemented

ORB Launcher is updated via the package manager, using an APT repository.

As such, nothing is automatically updated and users always control if/when they want to install updates.

In addition, ORB Launcher does not contain any code to update itself, as such, it is technically impossible for us to push “silent” or automatic updates.

Don´t run as root

Status: Implemented

By design, the ORB Launcher never runs as root, not even to mount the ISO or squashfs file.

In order the mount those files FUSE (Filesystem in Userspace) is used.

Don´t run with SUID

Status: Implemented

By design, none of our programs uses “SUID” permissions

In order the mount the required files, we use FUSE (Filesystem in Userspace).

Don´t mount with SUID

Status: Implemented

ISO and squashfs files are explicitly mounted without SUID permissions.

Require ORB to be marked as executable

Status: work in progress

As a security measure, ORB Launcher can require all ORB files to be marked as executable before running them.

This feature is currently being developed but might not be enabled by default

Update checking + alerts

Status: work in progress

We are working on an update system. This system checks if there is a more recent version of a particular ORB and, if desired, alerts the user.

Users should be able to completely disable this feature, if desired.

Distinctive icons

Status: Partially implemented, disabled by default

It should be clear to the user, even before trying to open an ORB, if the file is signed/trusted or not.

To do this we are considering implement a system of icons/symbols to differentiate the files.

Permission system

Status: work in progress

A “Permission” system will mean all apps must declare the permissions/functionality that they require.

The system must secure yet reasonably simple and yet reasonably simple for the users.

Ideally, users should be able to choose (via a simple graphical interface) which permissions they want to give to the Apps.
For example: Running a single-player game without the “internet” permission

Example permissions could be:
“Internet” “root” “read external media (CDs / USBs / etc)” “Access camera” “Access microphone”


Status: work in progress

We plan to have all non-signed software sandboxed in the longer term.

Sandboxing will, ideally, also extend to signed applications.

Potential options:

Source-based installers

Status: Not Implemented

Source-based installers, (in particular, Superdebs) would allow us to distribute a single ORB with source code and the scripts to compile and install that software.

This would make “reproducible buils” un-necessary and encourage distribution of source-code.

In addition, a single installer could be distributed to several computer architectures, unlike pre-compiled software that is specific to just one computer architecture.

We currently do not have any prototype of this type of installers.

Explicit user approval before running “non-trusted” software

Status: Implemented but disabled by default

We can, in the future, require users to first approve the running of “non-signed” and “non-whitelisted” software.

This would would presented as a simple explanation and a web link to further documentation.

This decision is being evaluated and will partially depend on the community feedback

Software “Blacklist”

Status: Not Implemented

An ORB “Blacklist” would contain “bad” software, like malware or software with very serious bugs (like the one that deleted the entire /usr directory)

We feel a blacklisting approach is fundamentally flawed and do not plan to implement this feature.

Secure ORB creation available to third-parties

Status: Not Implemented

Ideally, users would be able to use a web-based tool to create Portable ORB Apps and Superdebs. These ORB Apps would be signed by the server and, as such, could be distributed without security issues.

This is a long-term goal and we are currently not working of this feature.

Hardware-based security

Status: Not Implemented


We are considering improving the signing process by using an HSM (Hardware Security Module) or another hardware-assisted cryptography solution.

Potential solutions:

Reproducible builds

Status: Not implemented

In simple terms “Reproducible builds” means the same source code always produces the exact same output/binary.

For software like ORB Launcher this is not critical since it is mostly script-based.

Ideally, the ORB file themselves would be “reproducible”, ideally from pure source-code or at least from upstream pre-compiled software.

Physical security

Status: Implemented

We currently have several layers of physical security at the main build site, and plan to add additional security measures.


If you have any ideas, suggestions or criticism, feel free to send us a message.