package registry metadata自体がsupply-chain trust boundaryになる
package managerのsecurityではartifactそのものに注目しがちだが、どのartifactをdownloadし、どの検証方法を適用し、どのfileを実行可能物として公開するかを決めるregistry metadata も重要なtrust boundaryである。
aquaはupstream releaseを正規化するパッケージマネージャーと捉えられる と aqua Registryはupstream releaseの不統一を正規化する のaquaでは、この点が分かりやすい。Registry entryはrelease asset名、URL、version rule、supported environment、checksum、Cosign/SLSA/GitHub Artifact Attestations等のverification設定を持つ。
つまりregistry metadataが改竄されれば、単にpackage一覧が変わるだけではない。
- 別のrelease assetを選ばせる
- 別URLからartifactを取らせる
- supported platform判定を変える
- verification設定を変える
- archive内の別fileをcommandとして露出させる
といった影響を持ち得る。
このためartifact verificationが強くても、「何をverification対象として選んだか」を決めるmetadataの由来が弱ければsystem全体のtrustは弱くなる。
aquaはv2以降、Standard Registry以外をdefaultでは許可せず、custom registry利用時にPolicyを要求する設計を採っている。公式security documentationもcentrally managed Standard Registryをsecurity featureの一つとして位置付けている。これはregistryそのものを信頼境界として扱っている例である。
miseのaqua backendには別の興味深い設計がある。miseはaqua CLIを呼ばず、release時点のaqua registry snapshotをbinaryに組み込む。defaultではこのbundled snapshotを使い、current official registryを先に見るregistry_floatingはopt-inである。mise documentationは、floating registryにはinstalled mise versionがtestされた後の変更が入る可能性があるため、defaultではsnapshotを優先すると説明している。
これは registry freshnessとreproducibilityのtrade-off を示す。
- registryを固定する: 同じmanager versionで同じmetadataを使いやすいが、新しいplatform fixやsecurity metadataをすぐ取り込めない
- registryをfloatする: upstream registry修正をすぐ得られるが、同じconfigでも後日別metadataで解決され得る
この問題は署名検証だけではrollback・freeze attackを防げないとも関係するが同一ではない。rollback/freezeはattackerが古い正規metadataを提示する問題であり、registry pinningはuserがどの変更頻度を許容するかというreproducibility policyでもある。
またregistry schemaの表現力もtrust surfaceへ影響する。installer scriptを許すほどpackage managerのtrust surfaceは広がる のように任意scriptを許すregistryならmetadata compromiseが直接arbitrary code executionへ繋がりやすい。download/unarchive中心のdeclarative registryなら可能なside effectを狭められるが、それでもartifact selection authorityは残る。
package managerのtrust chainは、単純には次のように分けられる。
package config -> registry metadata -> selected artifact -> artifact verification -> installed executable
各矢印で「誰の主張を信頼して次のobjectを選んでいるか」を確認する必要がある。artifactに署名があることだけでは、その手前のregistry selectionを自動的に安全にはしない。