Engineering journal
Verifying a Software Component Before Execution
MakopaOS binds component bytes to signatures and source evidence, while deliberately keeping admission authority false. A precheck and permission to execute are separate decisions.
Source: https://louijiecompo.com/writing/verifying-a-component-before-execution/
About 2 min read
A successful verifier can establish something useful without authorizing execution. MakopaOS makes that distinction visible in the output: even a passing OS041A precheck returns admission_authority: false.
The component-admission core (opens in a new tab), merged in PR #22, is a separate host tool. It does not boot the operating system, compile a component, instantiate it or execute its code.
Bind the claim to the exact bytes
Three fixed-record parsers check admission, execution-profile and build-evidence records. Supporting documents must satisfy exact length, digest, syntax and ordering rules. SHA-256 bindings connect the component, supplied WIT, metadata, source manifest, configuration, transcript, dependency lock and tool-version bytes.
Domain-separated key IDs and strict Ed25519 verification constrain the signature boundary. A signature check belongs to an exact message and supplied public key; it is not a general declaration that arbitrary component behavior is safe.
The staged source inventory is checked independently for paths, modes, lengths, hashes, missing files, extra files and symlinks. Final component bytes and supplied WIT are checked against a constrained profile. Malformed, oversized, duplicate or mismatched input fails closed. Reports use stable categories and omit input paths.
Preserve the missing gates
OS041A remains in progress. Reconstruction from committed Git objects, production of the pinned fixture, contained metadata decoding, exact semantic graph comparison, contained compile-only measurements and link/disassembly evidence remain future gates.
Those missing steps explain the authority field. The implementation can report that its present checks pass while preserving the broader decision as unresolved. The target runtime remains separate from the host tool's dependencies, and no component execution path is added by this slice.
Compare it with repository trust
The Yocto and QEMU repository-trust evaluator has a related evidence boundary at a different layer. It compares a versioned desired-state policy with a separately collected observation. A matching snapshot does not establish continuous hosting-service enforcement.
| Layer | Present check | Claim still outside the check |
|---|---|---|
| Repository | Compare observed settings with a versioned policy. | Continuous compliance or collector authenticity. |
| Component | Check bounded bytes, signatures and supplied evidence. | Complete admission or permission to execute. |
These tools do not compose into a security certification. They illustrate a useful engineering practice: name the exact decision, preserve unavailable evidence, and keep verification separate from the authority that would act on it.
The MakopaOS case study shows the implemented boundary and remaining gates. This article reviews pinned public source and documentation; it does not claim a new kernel run, independent cryptographic audit or executed component.