Binary Distribution

1. Abstract

This RFC covers how Aura ships: platform matrix for the toolchain and for user applications, installers, archive layouts, code signing, checksums, self-update, and packaging of single-file app binaries. Default application deploy remains one executable produced by aura build.

Toolchain today (2026-08-17, S2): 0.1.1-alpha.8 is the next alpha after v0.1.1-alpha.7, with artifacts for Linux amd64/arm64 and macOS amd64/arm64. The installer uses versioned $AURA_HOME; cargo install --path crates/aura-cli uses the embedded runtime.c. Tag v* produces multi-OS tarballs, per-archive checksums, an aggregate SHA256SUMS, and a detached minisign signature; production tags fail closed unless both signing secrets are configured and the workflow verifies the signature. Windows amd64/arm64 remain tier2 policy targets and are not published.

2. Motivation

2.1 Problem statement

A language that compiles to native code still fails users if the toolchain is hard to install or app artifacts are multi-file messes. Distribution is part of the product.

2.2 Why now

Build outputs (RFC-008) and CLI (RFC-012) need install and release contracts.

2.3 Success metrics

3. Goals

• Document supported OS/arch matrix for v1.
• Standard release artifact naming.
• Signing & verification story.
• Self-update for toolchain (optional but designed).
• Clear guidance for app distribution (not an app store).

4. Non-goals

• App Store / Play Store submission pipelines.
• WASM distribution as v1 primary.
• Guaranteeing notarization on day-one for all platforms (track per-OS requirements).

5. Prior art & alternatives

6. Design

6.1 Platform matrix (v1)

The machine-readable policy is scripts/release-targets.tsv. required rows are built, checksum-checked, and installer-supported. tier2 rows are explicit policy commitments only and must not be described as shipped until native build and install evidence exists.

The current required artifact suffixes are linux-amd64, linux-arm64, darwin-arm64, and darwin-amd64; windows-amd64 and windows-arm64 remain tier2 policy rows and have no release assets yet.

Musl/static Linux: stretch goal for super-portable apps.

6.2 Toolchain artifacts

Naming:

aura-toolchain-{version}-{os}-{arch}.tar.gz
aura-toolchain-{version}-{os}-{arch}.zip   # windows

Contents:

bin/aura
lib/…          # if needed
share/…        # licenses, man
components…    # optional cross libs

6.3 Application artifacts

• Default: target/release/<bin> single executable.
• Optional: aura pack produces versioned tarball with binary + LICENSE + README (still one primary bin).
• Embed version via build: aura build --release sets version from manifest.

6.4 Install methods

6.5 Integrity & signing

• Publish SHA256SUMS for every release.
• Sign sums with release key (minisign for simplicity of offline verify; cosign optional later for provenance). Production release tags fail closed when signing material is absent; unsigned rehearsals must not be promoted to a release.
• Windows Authenticode / macOS notarization: platform-specific checklist.

6.6 Self-update

• aura toolchain upgrade checks release API, verifies signature, replaces binaries atomically.
• Respects offline mode.
• Channels: stable, beta, nightly (optional).

6.7 Container story

• Official slim images optional; still demonstrate copying single static binary into FROM scratch / distroless when linked appropriately.

6.8 Examples

# install toolchain (illustrative)
curl -fsSL https://aura.dev/install.sh | sh

aura version
aura build --release -o greeter
scp greeter host:/usr/local/bin/

6.9 Error model / edge cases

6.10 Compatibility & migration

• Toolchain versions independent of language editions.
• App binaries: no guarantee to run under different runtime major if dynamically linked—static default avoids this.

7. Open questions

8. Rationale & trade-offs

Single-file apps maximize operational simplicity. Toolchain archives + checksums are table stakes for professional languages. Self-update improves DX but increases supply-chain criticality—hence signatures. Cost: platform signing bureaucracy (Apple/Microsoft) is ongoing ops work.

9. Unresolved / future work

• Deb/rpm official packages
• SBOM generation on release
• Provenance (SLSA) levels

10. Security & safety considerations

• Install scripts are sensitive—pin versions, document checksum verification alternative.
• Release keys offline / HSM policy.
• Rollback path for bad toolchains.
• Do not auto-exec downloaded app code.

11. Implementation plan (optional)

The alpha gate validates the target manifest against the workflow, package script, installer, and this RFC before assets are built.

For alpha acceptance, a native target report is valid only when it records a successful binary execution on the matching OS/architecture; cross-file reports record format inspection and explicitly state that execution did not occur. This is intentionally weaker than foreign-host acceptance. Linux arm64 and Windows promotion still require native package/install/run evidence on their declared runners, and a production release still requires an actual tag-triggered signature verification using configured GitHub credentials.

12. References

• Go install/dist; rustup
• RFC-000, RFC-008, RFC-012

Changelog