kas: one configuration file for a bitbake based build

The gap between step 1 and step 2 of a bitbake workflow

kas is a setup tool for bitbake based projects, and the reason it exists is a specific gap in the OpenEmbedded workflow.

The documentation states the problem directly: the OpenEmbedded tooling support starts at step 2 with bitbake, and the downloading of sources and then configuration has to be done by hand, and that is usually explained in a README. Instead, kas uses a project configuration file and does the download and configuration phase.

That framing is useful, because it says exactly what the tool is and is not. It is not a Yocto build system, and it does not replace bitbake. It removes the manual part that sits in front of bitbake, the part where a person clones five layers at the right revisions, writes a local.conf with the right machine and architecture, and remembers which environment variables to export.

The key features are listed as four, and each is a step in that manual sequence. It clones and checks out bitbake layers. It creates default bitbake settings, the machine, the architecture and the rest. It launches a minimal build environment, reducing the risk of host contamination, which is the practice of building inside a container or an isolated shell so that the packages and environment variables on your workstation cannot leak into the image. And it initiates the bitbake build process.

So the shape is: one file describes the project, and kas turns that description into a running build. The documentation site at kas.readthedocs.io carries the full details.

The project configuration file replaces the README

The repository ships four example project files, and they are the best way to see what a kas project looks like. There is examples/isar.yml for the ISAR setup, examples/oe-core-nodistro.yml for an OE core without a distribution, examples/openembedded-buildtools.yml for the build tools, and examples/openembedded.yml for the full OpenEmbedded setup.

The point of having the configuration in a file rather than in prose is that it becomes reviewable. A README that says clone this layer at that branch and set this variable is a set of instructions that a person executes and that nobody checks. The same information in a project file is diffed, so a change of layer revision shows up in a pull request, and a new machine can be brought up by running one command rather than by following a checklist that was written for a different workstation.

The repository topics place kas in the OpenEmbedded and Yocto world, with isar and configuration management named alongside bitbake, so it sits in the same ecosystem as the tools it configures rather than beside them.

Two other things live in the same tree and are worth knowing about. There is a CHANGELOG.md and a SECURITY.md, and a docs/ directory that is published, since the readme points readers at kas.readthedocs.io for anything beyond the introduction. The .coveragerc, .flake8 and .coveragerc-adjacent files in the root tell you the project is a normal, tested Python package rather than a shell script collection.

The minimal build environment is the part that protects your host

Of the four features, the one with the most operational consequence is the minimal build environment, because it is what stops a build from depending on what happens to be installed on the machine running it.

A bitbake build needs a specific set of host packages, a specific Python, and a clean set of environment variables. On a developer workstation that is the normal state of affairs only by accident, and the usual result is that a build works for the person who set it up and fails for everyone else, including the CI runner. A minimal environment removes the question of what else is on the machine.

The repository supports that in several ways. There is a run-kas script at the root, a kas-container directory, a kas-docker directory, a container-entrypoint file and a Dockerfile, plus an image-tests directory that exists to check the container image itself. The Dockerfile is written for reproducible builds in a specific way, which tells you how seriously the project takes the environment question. It starts from a Debian trixie-slim base selected by a build argument, and it uses BuildKit cache mounts for the apt directories with a locking option, sets SOURCE_DATE_EPOCH as a build argument, pins LANG for the build locale, and keeps downloaded apt packages rather than cleaning them, which is what makes a subsequent layer build fast without changing the result.

The scripts/ directory holds the helper scripts, and contrib/ holds community contributions. The practical conclusion for an adopter is that the container path is the one that gives you the same result on a laptop and on a build server.

The security notice is the first thing to read

The README carries a security notice, and it is unusually direct about what the tool does not do.

At this stage, kas does not validate the integrity of fetched repositories. The instruction is to make sure to only pull from trusted sources to ensure that the selected revisions are the expected ones, specifically when using mirrors. Later versions of kas may introduce integrity validation mechanisms such as cryptographic checksums to strengthen supply chain security.

Read that carefully, because it changes what a project file is allowed to contain. The revisions in your configuration are honoured, and they are honoured without verification. That is a reasonable design for a tool whose inputs are layer repositories you already trust and pin, and an unreasonable one for a configuration that points at a mirror you do not control. A mirror that serves a different tree at the same URL is exactly the case the notice calls out.

There is a SECURITY.md in the repository root as well, which is where the disclosure process for a project like this is normally described.

For a build system, this is the correct place to be careful, because the output of the build is an image that people install. The mitigation is not sophisticated: pin to commit hashes rather than branches, prefer the canonical repositories over mirrors, and treat any change to the revision list in a project file as a change that deserves the same review as a change to a dependency lock file.

The packaging, the runtime and who maintains it

kas is a Python package with a pyproject.toml that names it, gives the description as a setup tool for bitbake based projects, and requires Python 3.9 or later. The classifier list includes Development Status 5, Production/Stable, and the maintainer is Jan Kiszka of Siemens, and the copyright lines in both the pyproject.toml and the setup.py run from 2017 to 2025 for Siemens AG.

The project carries both a pyproject.toml and a setup.py, and the setup.py is a shim that imports the version from the package and calls setup(), which is the transitional arrangement many projects use to move to a PEP 517 build. The build backend is setuptools with setuptools 40.5 or newer and wheel.

The repository is not archived and the last push was on 2026-10-16, and there are no GitHub releases, so the version in the package is what you get rather than a tagged release series. The CI configuration is visible in the README as two workflows, one for the master branch and one for next, which is the usual pattern of testing the stable line and the development line side by side.

The licence is MIT, and it is the standard MIT text in both the pyproject.toml and the setup.py, which is a nice detail for a project where the licence file and the packaging metadata are two separate places that can disagree.

Where kas is the wrong tool

Three limits follow from the design, and they are worth being blunt about.

The first is the starting point. The OpenEmbedded tooling support starts at step 2 with bitbake, so kas assumes that the environment before bitbake, the host tooling and the layer bootstrap, is already in place. If your project has not solved that yet, kas is not where the work is.

The second is the integrity gap described above. There is no checksum verification of the fetched repositories, which means kas is a convenience layer over a trust decision that you still have to make yourself. In a regulated environment where the supply chain has to be provable, that is a requirement you cannot satisfy with this tool as it stands.

The third is that the tool is specific to bitbake. It is not a general build orchestrator, and there is nothing in it for a project built with CMake, Bazel or Cargo.

The alternative approach is the one it replaces, and it is not unreasonable: keep the setup instructions in a README and run them by hand, or encode them in a container image built from a Dockerfile. The difference in approach is where the layer set, the target and the revisions live. With kas they live in one YAML file that a tool reads; with the manual approach they live in human-readable instructions, which are easier to follow and easier to talk about, and which nobody verifies.

A container image built for the build is the closest comparison, and kas and the container approach are complementary rather than exclusive, since the kas Dockerfile is itself a way of building the minimal environment. The practical question is whether your layer set changes often enough for a tool that reads it to pay for itself.

Editorial conclusion

Adopt kas if you build OpenEmbedded, Yocto or ISAR images and your layer set, target and revisions are currently written down as README instructions that somebody has to follow by hand each time. Do not adopt it for a project that has not yet reached the bitbake stage, since the tool starts at step 2 of the OpenEmbedded workflow, and do not point it at mirrors you do not control, because the tool does not validate the integrity of the repositories it fetches. Verify first that the revisions pinned in your project file are the ones you expect, that the minimal build environment contains the host packages your layers need, and that the container path you use is reproducible on your CI runner.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. siemens/kas on GitHub