Security

Keru's security stance follows from its design. No binaries, no opaque machinery, no hidden services. That shrinks the attack surface to things you can actually read.

Source-only by construction

There is no binary package store to compromise. Every package is compiled in your install from original source fetched over the network. The "prebuilt artifact" class of attack simply doesn't exist.

Verified fetch

• Mirror then upstream. Downloads prefer the project mirror and fall back to upstream, never the other way.
• Integrity enforced. A fetched tarball that doesn't verify is refused, not untarred. Failed verification is a hard stop.
• Pinned sources. Recipes pin the exact url and version. Nothing is ever pulled "latest" implicitly.

A toolchain you can audit

The whole vertical slice from "make.conf" to "booted system" is a handful of shell files. That's the honest counter to the "trust the distro binary blob" model.

Privilege by your rules

Privilege elevation is swappable: doas (slender, auditable) is the default, with sudo, opendoas, and plain su available. Keru never preloads root-owned services or hidden daemons.

Kernel hardening, if you want it

Pick linux-hardened at install for a hardened kernel, or stick with stable linux. The choice is yours and applied at the moment your system is built.

Licensing, because supply chain is security

All three repos are AGPL-3.0. Recipes tag their license explicitly. Nothing in the pipeline is proprietary-black-boxed.

Reporting

Found a flaw in the installer, kama, or a recipe? File it with the stage and the failing artifact. See contact and troubleshooting.

← Troubleshooting · Toolchain bootstrap →