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

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 (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 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 (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 (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 (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 demonstrates how the system refuses to load configuration when the trusted SHA is unavailable:

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:

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:

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 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 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 reads .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 and 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 in their pull request?

No. The trust boundary model explicitly ignores the .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 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 (lines 143-173 and 321-338) handles trusted SHA resolution and config loading; internal/config/config.go (lines 597-607) implements the merging logic via EffectiveRepoConfig; and the execution safeguards appear in internal/daemon/manager.go (lines 378-384) where runtime operations consume only the effective configuration.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}