# Repository Config Trust Boundary in No-Mistakes: Security Model and Implementation

> Understand the repo config trust boundary in No-Mistakes. Secure your repository by isolating trusted configurations from untrusted pull requests, preventing unauthorized code execution or modifications to safeguards.

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

---

**The repo config trust boundary is a security mechanism that isolates trusted configuration from the repository's default branch (e.g., `main`) from untrusted configuration in pull requests, ensuring that only vetted settings can enable code execution or modify project safeguards.**

The **kunchenguid/no-mistakes** repository implements a strict trust boundary to prevent supply-chain attacks. This boundary ensures that sensitive configuration options—such as enabling arbitrary commands or disabling project settings—can only be changed by committing to the protected default branch, not by external contributors through feature branches. Understanding this boundary is essential for securing CI/CD pipelines against configuration injection attacks.

## How the Trust Boundary Works

The trust boundary operates by maintaining two distinct configuration sources: **trusted** configuration from the repository's default branch HEAD, and **untrusted** configuration from the current working branch or pull request.

### Trusted vs Untrusted Configuration Sources

When the daemon processes a run, it resolves the commit SHA of the default branch (`origin/main`) and treats this as the **trusted SHA** (`trustedSHA`). The [`.no-mistakes.yaml`](https://github.com/kunchenguid/no-mistakes/blob/main/.no-mistakes.yaml) file is read specifically from this trusted commit, not from the checked-out working directory. According to the source code in [`internal/daemon/manager.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/manager.go), this isolation prevents malicious contributors from self-approving dangerous capabilities:

```go
// internal/daemon/manager.go
// Resolve the trusted SHA from default branch
trustedSHA := resolveDefaultBranchSHA(ctx, repo)
if trustedSHA == "" {
    return nil, fmt.Errorf("cannot resolve trusted default branch")
}

// Load config ONLY from trusted SHA
trustedRepoCfg := loadTrustedRepoConfig(ctx, workDir, trustedSHA, run.ID)

```

### Abort on Trusted Config Failure

If the daemon cannot fetch, read, or parse the [`.no-mistakes.yaml`](https://github.com/kunchenguid/no-mistakes/blob/main/.no-mistakes.yaml) file from the trusted SHA, the operation **must abort loudly** rather than falling back to untrusted sources. The `assertGateTrustedConfigReadable` function enforces this strict failure mode:

```go
// internal/daemon/manager.go
// SECURITY: a trusted-config fetch failure must abort, not silently disable
if err := assertGateTrustedConfigReadable(ctx, workDir, repo.DefaultBranch, trustedSHA); err != nil {
    return nil, fmt.Errorf("security abort: trusted config unreadable: %w", err)
}

```

This hard-fail approach prevents "trust-drift" attacks where a network error or git failure might accidentally cause the system to execute using untrusted configuration.

## Security Enforcement Mechanisms

The trust boundary controls access to security-critical configuration fields through explicit gating logic.

### Trusted-Only Configuration Fields

Certain high-risk settings are only honored when defined in the trusted configuration. As documented in [AGENTS.md at line 88](https://github.com/kunchenguid/no-mistakes/blob/main/AGENTS.md#L88), these include:

- **`disable_project_settings`** – When set to `true` in the trusted config, this disables user-provided overrides, ensuring centralized control.
- **`allow_repo_commands`** – Permits execution of repository-defined commands only when explicitly enabled in the trusted default branch configuration.

Other execution-related fields (such as `commands.test` or `commands.lint`) are read from the pushed branch only **after** the trusted config has been successfully loaded and validated.

### The Default Branch Resolution

The `resolveDefaultBranchSHA` function fetches the latest commit from the protected default branch, creating an immutable reference point for trusted configuration:

```go
// Conceptual flow from internal/daemon/manager.go
trustedSHA := resolveDefaultBranchSHA(ctx, repo) // fetches origin/main
trustedCfg := loadTrustedRepoConfig(ctx, workDir, trustedSHA, run.ID)
allowRepoCommands := trustedCfg != nil && trustedCfg.AllowRepoCommands

// Merge configurations with trust hierarchy
cfg := config.Merge(globalCfg, config.EffectiveRepoConfig(repoCfg, trustedCfg, allowRepoCommands))

```

If `trustedSHA` is empty or the file cannot be read at that specific commit, the system returns an error before processing any repository-defined commands.

## Source Code References

The trust boundary implementation spans several key files in the **kunchenguid/no-mistakes** repository:

- **[`internal/daemon/manager.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/manager.go)** (lines [444-512](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/manager.go#L444-L512)) – Contains `loadTrustedRepoConfig`, `assertGateTrustedConfigReadable`, and the core security logic that enforces the boundary.
- **[`AGENTS.md`](https://github.com/kunchenguid/no-mistakes/blob/main/AGENTS.md)** (line [88](https://github.com/kunchenguid/no-mistakes/blob/main/AGENTS.md#L88)) – Documents the high-level security concept and rationale.
- **[`internal/e2e/repo_config_security_test.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/e2e/repo_config_security_test.go)** – End-to-end tests verifying that untrusted configuration cannot enable privileged commands.
- **[`internal/daemon/manager_gate_optout_test.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/manager_gate_optout_test.go)** – Tests for opt-out handling and abort behavior when trusted configuration is missing.

## Security Implications

Implementing a strict repo config trust boundary provides three critical security guarantees against supply-chain attacks:

- **Command Injection Prevention** – Contributors cannot modify [`.no-mistakes.yaml`](https://github.com/kunchenguid/no-mistakes/blob/main/.no-mistakes.yaml) in a pull request to enable arbitrary code execution (`allow_repo_commands`) or inject malicious build scripts, as these gates are only checked against the trusted default branch version.

- **Privilege Escalation Blocking** – The `disable_project_settings` flag ensures that project-wide security policies can only be weakened through deliberate commits to the protected branch, not through external contributions.

- **Configuration Integrity** – By requiring successful reading of the trusted configuration before processing any repository commands, the system prevents race conditions or partial trust states where malicious configuration might partially apply.

## Summary

- The **repo config trust boundary** separates trusted configuration (from the default branch) from untrusted configuration (from pull requests) in the **no-mistakes** daemon.
- The system resolves a **trusted SHA** from `origin/main` and exclusively reads [`.no-mistakes.yaml`](https://github.com/kunchenguid/no-mistakes/blob/main/.no-mistakes.yaml) from that commit using `loadTrustedRepoConfig`.
- **Security-critical fields** like `allow_repo_commands` and `disable_project_settings` are only honored from the trusted configuration source.
- The daemon **aborts execution** if the trusted configuration cannot be read or parsed, preventing fallback to potentially malicious settings.
- This model protects against supply-chain attacks by ensuring only vetted repository settings influence pipeline execution.

## Frequently Asked Questions

### What happens if the default branch is unavailable during a run?

If the daemon cannot resolve the default branch SHA or read the [`.no-mistakes.yaml`](https://github.com/kunchenguid/no-mistakes/blob/main/.no-mistakes.yaml) file from that trusted commit, the `assertGateTrustedConfigReadable` function returns an error and the run halts immediately. This hard-fail behavior prevents the system from executing with potentially untrusted configuration due to network errors or repository unavailability.

### Can a pull request modify the allow_repo_commands setting?

No. The `allow_repo_commands` field is part of the **trusted-only** configuration set. Even if a contributor includes `allow_repo_commands: true` in their pull request's [`.no-mistakes.yaml`](https://github.com/kunchenguid/no-mistakes/blob/main/.no-mistakes.yaml), the daemon only checks this value from the trusted configuration at the default branch HEAD. This prevents external contributors from self-approving arbitrary command execution.

### How does the trust boundary prevent "trust-drift" attacks?

The trust boundary prevents trust-drift through explicit SHA pinning and loud failure modes. By resolving a specific `trustedSHA` and validating that the configuration file exists and is readable at that exact commit before proceeding, the system ensures that temporary git failures or network issues cannot cause the daemon to accidentally use working-directory configuration. The `assertGateTrustedConfigReadable` check guarantees that any failure to read trusted configuration results in immediate termination rather than silent degradation to untrusted sources.

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

The high-level concept is documented in [AGENTS.md at line 88](https://github.com/kunchenguid/no-mistakes/blob/main/AGENTS.md#L88), while the implementation logic resides in [`internal/daemon/manager.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/manager.go) between [lines 444-512](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/manager.go#L444-L512). Additional security tests demonstrating the boundary's enforcement are located in [`internal/e2e/repo_config_security_test.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/e2e/repo_config_security_test.go) and [`internal/daemon/manager_gate_optout_test.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/manager_gate_optout_test.go).