Policies

Peios is an operating system, and its security model is one of its central features. If you believe you have found a vulnerability in any part of it, report it privately so a fix can land before the details are public.

How to report #

Email security@peios.org. Do not open a public issue, and do not include vulnerability details in commits, pull requests, or public discussion before a fix is released.

A useful report includes:

• The component and version (or commit) you tested — for example the kernel (PKM/KACS), peipkg, peinit, loregd, or an image built with a stated release.
• What you observed, and why you believe it crosses a security boundary. On Peios that usually means the KACS access-control model, the signing and verification chain, or the package and boot pipeline.
• Steps or code to reproduce it. A provium test is ideal but plain shell steps are welcome.

The machine-readable form of this policy lives at /.well-known/security.txt on this site, per RFC 9116.

What to expect #

Peios is developed by a small team, so the process is deliberately simple:

• You should normally receive an acknowledgement within a week.
• Reports are handled on a coordinated-disclosure basis: the details stay private until a fix is available, and you will be told when that happens. If you need a firm disclosure date, propose one in your report.
• Fixes ship in the next release, and the release notes credit reporters who want to be credited.
• There is no bug-bounty programme.

Scope #

In scope: every first-party Peios component — the PKM kernel tree, the userspace daemons and libraries, the packaging and image pipeline (pekit, peipkg, peiso), and the published images and packages themselves.

Vulnerabilities in third-party upstream software that Peios packages should go to the upstream project first; report them here as well when Peios's packaging or configuration makes the impact worse.

Where to go next #

• Licensing and source availability — the terms Peios ships under and how to get its source.

Peios is open source. This page states the licensing terms and the mechanisms that carry them through the packaging pipeline.

First-party code #

First-party Peios components are licensed under the MIT licence, copyright The Peios Authors. The exception is the PKM kernel tree: it is a derivative work of the Linux kernel and is therefore licensed GPL-2.0-only (with the Linux syscall exception), like the kernel itself.

Package licence metadata #

Every Peios package declares its licence as an SPDX expression in its manifest — GPL-3.0-or-later WITH GCC-exception-3.1, BSD-3-Clause, and so on.

The package format itself treats the field as optional, but pekit requires it for any peipkg-format package, so every package Peios publishes carries one. The metadata is complete by construction rather than by convention.

The licence texts themselves install with the software, under /usr/share/licenses/<package>/. Composed images additionally carry an aggregate inventory at /usr/share/licenses.json, listing every installed package with its version, licence expression, licence class, and source reference — an image can always answer what it contains and under what terms.

What Peios ships #

An SPDX expression says what a licence is; it does not say whether Peios considers the package free to redistribute. That judgement is a second manifest field, license_class, drawn from a closed set:

The policy is: Peios ships free software and device firmware, and does not ship proprietary userspace. Every package Peios publishes with a LicenseRef- term in its licence expression — which is exactly when the expression alone cannot answer — declares its class, and the composed-image inventory carries the class for every installed package, so a machine can state what non-free material it contains without parsing licence text.

Firmware is the one deliberate exception to "everything is free", and it is kept visible rather than folded in: it ships as its own family of packages, each under the vendor licence recorded for that family, with the licence text installed beside the blobs. Device firmware lists the families and explains how the kernel verifies what it loads.

Corresponding source #

For every package Peios builds from source, it publishes a companion source package (<name>-source) through the same channel as the binary. It installs under /usr/src/dist/<name>-<version>/ and contains:

• upstream/ — the pristine source input the build consumed, byte-for-byte; its hash matches the build recipe's committed lockfile, so you can verify it independently.
• patches/ — the patch series Peios applied, when there is one.
• recipe/ — the build recipe itself: the scripts that control compilation and installation.

Each binary package names its source package in its manifest, in the source_package field, and the aggregate inventory carries the same mapping. This is how Peios meets the source-availability obligations of copyleft licences such as the GPL: the corresponding source of every published binary is available from the place you got the binary, for as long as the binary is distributed.

The promise is about source, so it does not extend to packages that have none. Firmware packages redistribute the vendor's blobs as they are: the blob is the artefact, a source package would be the same bytes under another name, and the recipe turns the companion off. Such a package carries no source_package reference, and its license_class says why. That is the only ground for omitting a source package — licence terms are never one; a package whose licence forbids publishing source is a package Peios does not ship. The rule as it applies to recipe authors is in the peipkg reference, Building and signing.

Details of how source packages are produced are in the pekit documentation: sources and the lockfile.

Where to go next #

• Security policy — how to report a vulnerability.