# Trust Boundary Model in no-mistakes: How It Prevents RCE Attacks

> Discover the trust boundary model in no-mistakes. Learn how it prevents RCE attacks by isolating untrusted data and sourcing commands from immutable commit SHAs.

- Repository: [Kun Chen/no-mistakes](https://github.com/kunchenguid/no-mistakes)
- Tags: deep-dive
- Published: 2026-06-25

---

**The trust boundary model isolates untrusted contributor data from trusted maintainer configuration by sourcing executable commands exclusively from the default branch's immutable commit SHA, effectively blocking remote code execution by default.**

The `no-mistakes` repository implements a strict security architecture that prevents malicious pull requests from executing arbitrary code during automated runs. By establishing a clear **trust boundary** between contributor-submitted configuration and maintainer-controlled settings, the system ensures that potentially dangerous commands never execute without explicit maintainer approval.

## How the Trust Boundary Model Works

The implementation centers on resolving the repository's default branch to a specific commit SHA, then treating that snapshot as the single source of truth for executable configuration.

### Fetching the Trusted SHA

When the daemon initiates a run, it fetches the repository's default branch into a fresh work-tree and resolves it to an exact commit SHA. If this fetch fails, the trusted SHA remains empty, and the run proceeds with **no trusted configuration**—effectively disabling all potentially unsafe operations.

According to the source code in [`internal/daemon/manager.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/manager.go) (lines 321-338), the daemon performs this resolution before processing any contributor data, ensuring that the trust anchor is established independently of the code being tested.

### Loading the Trusted Configuration

The `loadTrustedRepoConfig` function enforces the boundary by reading [`.no-mistakes.yaml`](https://github.com/kunchenguid/no-mistakes/blob/main/.no-mistakes.yaml) **only** from the resolved trusted SHA. This function operates with three strict rules:

- If the SHA is empty or the file is missing, the function returns `nil`
- If the YAML parsing fails, the function logs a warning and returns `nil`
- Only successfully parsed configurations from the trusted SHA are returned as the *trusted repo config*

As implemented in [`internal/daemon/manager.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/manager.go) (lines 143-173), this function guarantees that malformed or missing trusted configurations fail safely by defaulting to nil, preventing any fallback to untrusted sources.

### Merging Trusted and Pushed Configurations

The daemon constructs the final runtime configuration using `config.EffectiveRepoConfig`, which prioritizes the trusted maintainer settings over contributor inputs. The merging logic follows a strict hierarchy:

1. The `allow_repo_commands` boolean is read **exclusively** from the trusted config
2. When `allow_repo_commands` is `false` (the default), the **commands** and **agent** fields from the pushed (contributor) config are discarded and replaced with trusted versions
3. Only the maintainer's default-branch copy determines whether repository-defined commands execute

This logic resides in [`internal/config/config.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/config/config.go) (lines 597-607), where the function signature accepts both the pushed and trusted configurations but always defers to the trusted source for security-critical decisions.

### Enforcing the Boundary at Runtime

All execution paths that invoke commands—such as lint, test, or format operations—reference only the *effective* configuration. Because `effectiveRepoCfg` sources its executable fields from the trusted SHA, any malicious script injected into a contributor's branch is filtered out before reaching the execution stage.

The runtime enforcement appears in [`internal/daemon/manager.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/manager.go) (lines 378-384), where the daemon uses `effectiveRepoCfg` to determine which commands to execute, ensuring that untrusted input never reaches the shell.

## Code Implementation Examples

### Loading the Trusted Config

The following simplified implementation from [`internal/daemon/manager.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/manager.go) demonstrates how the system refuses to load configuration when the trusted SHA is unavailable:

```go
func loadTrustedRepoConfig(ctx context.Context, wtDir, trustedSHA, runID string) *config.RepoConfig {
    if trustedSHA == "" { // no trusted SHA → no trusted config
        return nil
    }
    content, err := git.ShowFile(ctx, wtDir, trustedSHA, ".no-mistakes.yaml")
    if err != nil {
        slog.Debug("trusted repo config: not present on default branch", "run_id", runID, "sha", trustedSHA, "error", err)
        return nil
    }
    trusted, err := config.LoadRepoFromBytes([]byte(content))
    if err != nil {
        slog.Warn("trusted repo config: parse failed; commands/agent from pushed branch will be disabled", "run_id", runID, "sha", trustedSHA, "error", err)
        return nil
    }
    return trusted
}

```

### Computing the Effective Config

This snippet illustrates how the daemon prepares the final configuration, explicitly sourcing the permission flag from the trusted copy only:

```go
trustedRepoCfg := loadTrustedRepoConfig(ctx, wtDir, trustedSHA, run.ID)

// `allowRepoCommands` is *only* read from the trusted copy.
allowRepoCommands := trustedRepoCfg != nil && trustedRepoCfg.AllowRepoCommands
effectiveRepoCfg := config.EffectiveRepoConfig(pushedRepoCfg, trustedRepoCfg, allowRepoCommands)

```

### Running Commands Safely

At execution time, the daemon references only the effective configuration, ensuring that even if a contributor submitted `commands.lint: "rm -rf /"`, the trusted command (or no command) executes instead:

```go
if cmd := effectiveRepoCfg.Commands.Lint; cmd != "" {
    // This will be the trusted lint command (or empty if not allowed).
    execCommand(ctx, cmd)
}

```

## Security Guarantees and Test Coverage

The repository maintains comprehensive security tests that verify the trust boundary under various attack scenarios. The test suite in [`internal/e2e/repo_config_security_test.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/e2e/repo_config_security_test.go) validates that lint and agent commands from pushed branches are ignored unless the trusted default-branch explicitly enables them via `allow_repo_commands: true`.

Additionally, [`internal/daemon/manager_trust_test.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/manager_trust_test.go) confirms that a missing or stale trusted SHA yields a nil trusted config, thereby dropping all potentially unsafe commands and preventing RCE vectors when the repository state cannot be verified.

## Summary

- The **trust boundary model** separates untrusted contributor configuration from trusted maintainer settings by resolving the default branch to an immutable SHA.
- The `loadTrustedRepoConfig` function in [`internal/daemon/manager.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/manager.go) reads [`.no-mistakes.yaml`](https://github.com/kunchenguid/no-mistakes/blob/main/.no-mistakes.yaml) exclusively from the trusted SHA, returning nil if the file is missing or malformed.
- **`allow_repo_commands`** defaults to `false` and is read only from the trusted configuration, preventing contributor-defined commands from executing without explicit maintainer opt-in.
- The **`EffectiveRepoConfig`** function merges configurations by discarding untrusted executable fields when the permission flag is disabled.
- Comprehensive tests in [`repo_config_security_test.go`](https://github.com/kunchenguid/no-mistakes/blob/main/repo_config_security_test.go) and [`manager_trust_test.go`](https://github.com/kunchenguid/no-mistakes/blob/main/manager_trust_test.go) verify that the boundary prevents RCE attacks even when contributors submit malicious configuration files.

## Frequently Asked Questions

### What happens if the trusted SHA cannot be fetched?

If the daemon fails to fetch or resolve the default branch to a specific SHA, the `trustedSHA` variable remains empty. When `loadTrustedRepoConfig` receives an empty SHA, it immediately returns `nil`, causing the effective configuration to disable all repository-defined commands. The run proceeds using only safe defaults, preventing any potential RCE vectors from unverified sources.

### Can a contributor bypass the trust boundary by modifying [`.no-mistakes.yaml`](https://github.com/kunchenguid/no-mistakes/blob/main/.no-mistakes.yaml) in their pull request?

No. The trust boundary model explicitly ignores the [`.no-mistakes.yaml`](https://github.com/kunchenguid/no-mistakes/blob/main/.no-mistakes.yaml) file from contributor branches. The daemon reads this configuration file only from the trusted SHA (the default branch's current commit). Even if a contributor adds `allow_repo_commands: true` to their branch's copy, the system reads this permission flag exclusively from the maintainer-controlled default branch, rendering the modification ineffective.

### How does `allow_repo_commands` control remote code execution risks?

The `allow_repo_commands` boolean acts as a security gate that defaults to `false`. When disabled, the `EffectiveRepoConfig` function replaces the contributor's **commands** and **agent** fields with those from the trusted configuration (typically nil or maintainer-defined safe values). Only when a maintainer explicitly sets `allow_repo_commands: true` in the default branch's [`.no-mistakes.yaml`](https://github.com/kunchenguid/no-mistakes/blob/main/.no-mistakes.yaml) will contributor-defined commands execute, making RCE impossible without deliberate maintainer consent.

### Where is the trust boundary enforced in the codebase?

The boundary enforcement spans three critical locations: [`internal/daemon/manager.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/manager.go) (lines 143-173 and 321-338) handles trusted SHA resolution and config loading; [`internal/config/config.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/config/config.go) (lines 597-607) implements the merging logic via `EffectiveRepoConfig`; and the execution safeguards appear in [`internal/daemon/manager.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/manager.go) (lines 378-384) where runtime operations consume only the effective configuration.