Refusing to launch what changed

The sandbox has always answered one question: what a running application may reach. It never answered the other one. An installed application is a set of layers, a configuration and a permission set, and all of it lives in a store the user owns. Anything running as that user can edit it. A package with read-write access to the home can edit another package's layers, rewrite the permissions it runs with, and replace the launcher that would have checked. Nothing noticed, because nothing was looking.

cpak 2.6 writes down what an application is and checks it before every launch. The check has two halves and they are deliberately separate. One covers what the application is: its origin, its image, the ordered list of its layers and the store state each one produced, its binaries, desktop entries and sessions. The other covers what it is allowed to do: the permission set after the manifest and any override you applied. The two are combined into the value a launch is compared against.

Keeping them apart is not tidiness. It is what lets you narrow an application's permissions without reinstalling it, and what stops an update from quietly changing what an application may do while it changes what the application is.

The expectation lives where you cannot write it

Every other file a launch depends on belongs to the user, so a comparison between two files the user owns proves nothing. The record therefore lives under /var/lib/cpak/integrity, owned by root, one entry per user and origin, written through the same privileged service that registers login sessions. The account that starts an application cannot rewrite what that application is supposed to be.

Installing an application records it. Updating it records it again. Changing its permissions with cpak override, or enabling an addon, records it again as part of the same command: a narrower permission set goes through without asking, a wider one asks for an administrator password once. That is the same rule a permission manager already follows, applied to the thing that decides whether the application starts.

What is refused, and when

There is a level, and it governs exactly one thing: what happens to an application nobody has recorded. Off is the default and behaves as cpak did before. Warn refuses nothing and reports every disagreement, so a machine can be watched before anything is enforced. Refuse turns those into refusals.

A store that contradicts itself is a different matter and is refused at every level, including off. If a layer binding names a state the store no longer serves, or a prepared checkout is not the shape its recorded state describes, that is not an unknown, it is a disagreement inside the store, and there is no level at which it should start. Enforcement governs the unknown, never the known bad.

An installation made before this release has nothing recorded. It keeps working, it is reported by cpak audit, and cpak audit --backfill-bindings brings it up to date without reinstalling. When a launch is refused, cpak system explain puts what is recorded beside what the launch derives, so the disagreement can be read instead of guessed.

What this does not claim

Recording happens at install time, from what is on disk at that moment. That is a true statement about a machine whose owner is trusted, and it is the right guarantee for a desktop: one application can no longer change another, or its permissions, or the code that checks, without the next launch refusing. It is not authenticity. It does not prove a package came from its author, and nothing here pretends otherwise. Publisher signing is what makes that claim, and it is the next piece.

The comparison at launch is metadata: paths, kinds, sizes, permission bits and link targets. File contents are not read, because reading every byte of a large application costs seconds and a launch cannot pay that. Content is checked on demand instead. And on a machine whose owner is hostile to themselves, none of this holds, because they can simply not use it. Where the person at the keyboard does not control root, it holds completely.

Read the verified launch guide for the levels, the commands and the exact shape of the guarantee, or the sandbox guide for the boundary a running application works inside.