TEE Compile

Background

In the current technological landscape, there's a glaring absence of mechanisms to verify that an executable file has been compiled from a specific source code. This gap poses significant challenges in terms of security, transparency, and trust, as there is no definitive way to prove the authenticity of the compiled software.

To address this issue, TEE Compile standardizes the compilation process within an enclave environment. An enclave is a protected, isolated area of execution where code can run with confidentiality and integrity, safeguarded from tampering or unauthorized access. Because the build runs inside an attested enclave, anyone can verify that the published binaries really came from the published source.

Workflow

Roles:

• Action Runner: A self-hosted GitHub Actions runner on an AWS Nitro VM. It checks out the project code and launches the TEE Compile client when a build is triggered.
• TEE Compile: Responsible for compiling the source code into executable files. It is divided into two parts:
  • The Client runs the enclave. Since the enclave cannot communicate with the outside directly, the Client submits the source code to the Worker and saves the resulting executable files locally.
  • The Worker runs inside the enclave. It collects the relevant build information, compiles the project, and returns the executable files to the Client.

Initialization

1. The project owner runs an AWS Nitro VM and initializes it, including configuring it as a GitHub Actions runner and installing TEE Compile.

2. Download the corresponding language's enclave image (.eif) from a trusted source. Different languages and compiler versions have different images.

3. Create a build.json in the project root directory, for example:

   {
       "language": "rust",
       "input": {
           "cmd": "cargo build"
       },
       "output": {
           "files": [
               "target/debug/rust-project"
           ]
       }
   }

See Getting Started for the full runner and GitHub Action setup.

New Version Release

1. A GitHub Action triggers the BuildTool(Client) in the runner for compilation.
2. The Action Runner downloads the code and executes the BuildTool(Client), which scans the configuration files in the project and selects an enclave image based on the project configuration.
3. The BuildTool(Worker) obtains the code via the Builder, reading from the configuration files how to compile the project: the language, the compilation commands to execute, the information to collect, and the list of output files.
4. The BuildTool(Worker) executes the compilation, intercepting network traffic so that dependencies are controlled (see Vendorizing).
5. The BuildTool(Worker) collects the produced files, calculates their hashes, and generates an Attestation Report containing information about the input and output.
6. The executable files and Attestation Report are packaged into a tar file and output through the BuildTool(Worker) to the outside world — for example to a GitHub release — and ultimately provided to the project's users.

Report Verification

To verify a release, check:

1. Whether the hash of the produced executable files matches the report.
2. Whether the enclave image used for compilation is known to be trustworthy.
3. The issuer of the report.

Independent verifiers can also recreate the compilation environment described in the Attestation Report and compare the resulting build artifacts.