asm 0.7.0

Asm 0.7.0

Status: prerelease. Exact-host qualification and artifact digests accompany the release assets.

This release prepares native publishing, signed package distribution, complete dependency graphs, and hostable mirrors.
Application and package logic remain in assembly.
The embedded Go adapter supplies maintained HTTPS transport, TUF verification, and cryptography.
Earlier published versions retain their original bytes and licenses.

Supported hosts and build profile

Host	CLI artifact
Linux x86-64	asm-0.7.0-x86_64-linux
Linux ARM64	asm-0.7.0-aarch64-linux
Apple Silicon, macOS 15 or later	asm-0.7.0-aarch64-macos

The Linux builds use their native system-call interfaces and little-endian ELF64.
ARM64 requires ARMv8-A. No optional CPU extensions are declared.
The macOS build uses Apple arm64, Mach-O, and libSystem, with ad-hoc signing.
Developer ID signing, notarization, and a separately qualified minimum Linux kernel remain unavailable.
Intel macOS, Windows, and a native RISC-V CLI remain outside the released host matrix.

Ordinary make builds include V2 commands.
Source builds require the Go SDK declared in verifier/go.mod, plus the documented native tools.
make REGISTRY_V2=0 selects the explicit V1-only build without Go.
Make keeps different profile outputs separate.
The default release profile matches the ordinary source build.

Publish and consume exact releases

asm registry publish --project prepares archives from a committed Git project and submits them with a scoped Asm credential.
It does not require a GitHub account or a particular CI system.
GitHub, Entire, GitLab, Codeberg, other hosts, and local projects use the same publication contract.
A source locator describes origin; the enrolled owner and credential authorize publication.
Publication never builds or executes submitted code.

Native clients use an explicit registry identity, independently selected root, persistent trust directory, and up to three HTTPS mirrors.
Mirrors change transport without changing authority.
Signed lifecycle policy distinguishes yanking and emergency revocation.
Fetch and installation verify exact bytes without executing the package.
The V2 specification states freshness, clock, format, and resource limits.

asm registry resolve selects a complete source graph for one explicit target.
asm registry sync restores the retained selection without choosing newer versions.
Build checks validate the local lock, source declarations, and cached bytes.
They do not refresh remote lifecycle policy.
Optional dependencies remain dormant until an enabled feature activates their edge.
Named features can activate local features, optional dependencies, or a dependency's named feature.
Incoming requests combine additively for each selected package.
Use registry resolve --features NAME[,NAME] to select root features.
Use --no-default-features to disable the root's implicit default feature.
Dependency declarations separately control their requested child features and default feature.
An unknown child feature can cause selection of another compatible version.
Local feature cycles and malformed inactive declarations fail validation.

New resolutions write asm-lock-v4 with root choices, enabled features, active edges, and the complete selected graph.
Synchronization restores those choices without resolving newer versions.
Feature-free asm-lock-v3 files remain readable.
Feature-bearing projects require a new resolution instead of reusing v3 semantics.
Publication retains schema 2 with closed optional fields; earlier immutable envelope bytes remain unchanged.
Features control dependency selection; source imports and assembly symbols remain explicit.
See the hosting workflow for commands and failure recovery.

Host a registry or mirror

A byte mirror needs selected files or S3-compatible storage, synchronization, and HTTPS serving.
It needs no PostgreSQL database, publisher credential, or signing key.
Publishing needs the assembly authority, PostgreSQL, private objects, isolated checks, signing, and recovery operations.
The source archive includes those components, deployment recipes, and locked storage dependencies.
See the hosting guide for the minimal topology and operating limits.

Website builds can project V2 records and registry-scoped download observations.
Statistics are imported asynchronously from private origin logs.
Missing observations remain unknown; observed transfers are not unique people or executions.
Mirrors that do not supply logs do not acquire invented download counts.

Release evidence and limits

The release gate requires two clean builds and exact final-byte native tests on each supported host.
Receipts bind the selected client profile, embedded adapter, Go SDK, and dependency notices.
Per-host notice files accompany the executable assets.
The publisher validates the same-run artifact handoff before signing and never executes artifact input.
Published-byte, provenance, website, and first-project checks follow publication.
This document states the contract; it does not replace those results.

The hello and math source manifests also advance to 0.7.0 for the existing monorepo release recipe.
That recipe publishes new immutable example assets and checks each project's version against the release version.
Every earlier example archive and record remains unchanged.

The self-update trust profile remains disabled.
Bootstrap installation and asm self update retain the GitHub CLI provenance prerequisite.
An explicit V2 registry root does not activate the separate Asm self-update root.
Official hosted V2 publication remains gated on real trust custody, enrolled owners, provider identities, deployment pins, and recovery checks.
Public enrollment, ownership transfer, browser login, hosted builds, and hosted formal verification remain unavailable.

Package digests, signatures, tests, and proofs establish different properties.
None establishes that arbitrary package code is harmless.
Local builds remain outside a hermetic sandbox.
The security model and release plan retain these boundaries.