パッケージ · レッスン 2

パッケージリポジトリ

リポジトリが署名済みパッケージ索引を公開する仕組みと、APT が設定済みの Debian 系ソースを検出する方法を学びます。

パッケージリポジトリは、パッケージを索引やリリースメタデータとともに公開します。パッケージマネージャーは索引をダウンロードし、設定されたディストリビューションとアーキテクチャに適合するバージョンを選び、リポジトリの認証を検証して、必要なパッケージファイルを取得します。

リポジトリメタデータとローカルカタログ

リポジトリは単なるアーカイブのディレクトリではありません。メタデータには、利用可能なパッケージ名、バージョン、アーキテクチャ、チェックサム、依存関係、リポジトリセクションが記述されます。クライアントはローカルカタログをキャッシュするため、すべてのアーカイブを先にダウンロードせず、パッケージの検索と解決ができます。

Debian 系システムでは、設定済みメタデータを次のように更新します。

$ sudo apt update

これはローカルのパッケージ索引を更新するもので、利用可能なアップグレードをすべてインストールする操作ではありません。失敗した項目を無視せず、報告された情報源と認証エラーを確認してください。

apt update が主に更新するものは何ですか？

APT のソース設定

APT は次の両方から設定済みソースを読み取ります。

/etc/apt/sources.list
/etc/apt/sources.list.d/ 以下にある、.list または .sources で終わるファイル

.list 拡張子は従来の1行形式を使います。.sources 拡張子は deb822 形式のスタンザを使い、現在の APT 文書では新規設定に推奨されています。ディストリビューションは既定ソースをどちらにも配置できるため、/etc/apt/sources.list に完全な設定や主要な設定が必ず含まれるとは限りません。

deb822 形式のソースは次のようになります。

Types: deb
URIs: https://deb.example.invalid/repository
Suites: stable
Components: main
Signed-By: /etc/apt/keyrings/example.gpg

これは構文例にすぎず、予約された .invalid ドメインは利用可能なリポジトリではありません。

APT はどこから有効なリポジトリ定義を読み取れますか？

リポジトリの認証

APT は署名されたリポジトリのリリースメタデータを検証し、ダウンロードしたパッケージファイルを、その認証済みメタデータにあるチェックサムと照合します。Signed-By を使えば、そのリポジトリでグローバルに設定された全鍵を信頼するのではなく、特定のキーリングへソースを限定できます。

有効な署名から分かるのは、受け入れた署名鍵の所有者からメタデータが届き、検出されない変更を受けていないことです。公開者のソフトウェアに欠陥や悪意がなく、そのシステムに適していることまでは証明しません。鍵のフィンガープリントとソースの手順は、独立した信頼できる経路で確認してください。

APT ソース定義における Signed-By のセキュリティ上の目的は何ですか？

第三者ソースを意図的に追加する

リポジトリはシステム権限でパッケージとライフサイクルスクリプトをインストールできるため、追加するとシステムのソフトウェア信頼境界が広がります。追加前に次を行います。

要件を満たすならディストリビューションのリポジトリを優先する。
公開者、対応リリース、アーキテクチャ、署名鍵のフィンガープリントを確認する。
専用のソースファイルと、範囲を限定したキーリングを使う。
インストール前に、パッケージ名と依存関係の変更を確認する。
ソースを無効化し、そのパッケージを移行または削除する方法を文書化する。

署名確認を無効化したり、監査していないリモートスクリプトを特権シェルへパイプしたりする古い手順をコピーしてはいけません。

第三者リポジトリの追加がシステムの信頼境界を広げるのはなぜですか？

Linux でのソフトウェアインストールでリポジトリを使うインストールを練習するか、YUM でパッケージを照会・更新するで Red Hat 系のワークフローと比較してください。APT の正確な構文は、ローカルの sources.list(5) マニュアルを参照します。

レッスン完了