Project

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, and source reference — an image can always answer what it contains and under what terms.

Corresponding source #

For every package built from an external source, Peios 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.

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.