aquaはupstream releaseを正規化するパッケージマネージャーと捉えられる

aquaはNixのようにbuild graphから成果物を導く仕組みとはかなり違う。中心にあるのは、GitHub ReleasesやHTTP配布物など、upstreamが既に公開している実行可能artifactをversion・OS・architectureに応じて選び、取得・展開することである。

ビルド済みパッケージ配布を一括りにしない の分類では upstream release adapter 型とみなせる。

aquaのRegistryはpackage一覧だけでなく、asset名のtemplate、OS/architecture名の置換、versionごとの例外、対応platform、展開後の実行ファイル位置などを記述する。例えばupstreamがfoo_1.2.3_Linux_x86_64.tar.gzのような独自命名をしていても、registry側がreplacementsやversion_overridesで吸収できる。

このためaqua Registryは単なるindexではなく、不統一なupstream release schemaを共通のinstall modelへ変換する知識ベースとして機能している。この論点は aqua Registryはupstream releaseの不統一を正規化する に分けられる。

またaquaは「prebuilt binaryしか扱えない」とまでは言えない。package typeとしてgo_install、go_build、cargoなどを持ち、さらにgithub_releaseでprebuilt assetがないplatformだけbuildでGoから構築するfallbackも用意している。ただし通常のinstaller scriptを自由に実行するモデルではなく、公式ドキュメントではinstallを基本的にdownload + unarchiveへ限定することを、simplicity・security・dependency削減のための設計として説明している。この境界は installer scriptを許すほどpackage managerのtrust surfaceは広がる に繋がる。

security面では、aquaはassetそのものに加えてchecksum、Cosign、SLSA Provenance、Minisign、GitHub Artifact Attestations等をregistry metadataで表現できる。ただしchecksum verificationはpackage設定に依存し、checksumがあることと、そのchecksumの発行者を真正と確認できることは別問題である。checksum・signature・provenanceは別の保証をする でこの差を分離する必要がある。

さらにaqua v2ではStandard Registry以外をPolicyで制限する設計が導入されている。これは、registry metadata自体が「どのURLから何を取得し、何を実行可能物として扱うか」を決めるため、binaryそのものだけでなくregistryもsupply-chain trust boundaryになるからだ。この点は package registry metadata自体がsupply-chain trust boundaryになる に繋がる。

Nixとの対比では、Nixが「build resultをcacheから代入する」のに対し、aquaは「upstreamが公開したrelease artifactをregistryの規則で選択する」と表現すると違いが明確になる。前者ではbuild definitionとcache resultの対応が中心問題になり、後者ではupstream release naming、platform matrix、release authenticityの扱いが中心問題になる。

#ツールチェーン #security

出典

• aqua: Registry
• aqua: Registry Configuration
• aqua: github_release Package
• aqua: build
• aqua: Restriction
• aqua: Security
• aqua: Policy as Code
• aqua: checksum
• aqua: Cosign and SLSA Provenance