サードパーティのAPTパッケージリポジトリを追加する際に使用する
リポジトリの正当性を担保する仕組み
Linuxにおけるパッケージ管理システムは、
- パッケージに悪意のあるコードが含まれていないこと
- パッケージメンテナ以外の第三者が作ったパッケージがリポジトリにアップロードされていないこと
- 本来のリポジトリとは別の場所からパッケージをダウンロードしていないこと
まず一番気になる1についてですが、
2も厳密にはAPTの対象外です。Ubuntuの公式リポジトリの場合は、
APTで正当性を確認するのは、
この
- sources.
listに記録されているURLからInReleaseファイルをダウンロードする - InReleaseファイルを、
ローカルにあらかじめ保存しておいたリポジトリ鍵で検証する - main/
binary-amd64/ PackagesなどのPackagesファイルをダウンロードする - Packagesファイルのハッシュを、
InReleaseの中の情報で検証する - Packagesのパスに応じてpool/
main/ 以下などから、対象のパッケージファイルをダウンロードする - ダウンロードしたパッケージファイルのハッシュを、
Packagesファイルの中の情報で検証する
InReleaseに対する署名は、
たとえばUbuntu 20.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Origin: Ubuntu Label: Ubuntu Suite: focal Version: 20.04 Codename: focal Date: Thu, 23 Apr 2020 17:33:17 UTC Architectures: amd64 arm64 armhf i386 ppc64el riscv64 s390x Components: main restricted universe multiverse Description: Ubuntu Focal 20.04 （中略） 7ef83228ec207df10acac48fbdd81112 5826751 main/binary-amd64/Packages （中略） +m9MS1XP0RN13iWp3zXSlWJGPO/mDezqQ7vZ8Iwx =7xQ1 -----END PGP SIGNATURE-----
Packagesも含むメタデータ情報のURLが示すコンテンツごとの、
それに対してリポジトリからダウンロードできる、
Package: accountsservice Architecture: amd64 Version: 0.6.55-0ubuntu13.2 Priority: standard Section: gnome Origin: Ubuntu Maintainer: Ubuntu Developers <[email protected]> Original-Maintainer: Debian freedesktop.org maintainers <[email protected]> Bugs: https://bugs.launchpad.net/ubuntu/+filebug Installed-Size: 452 Depends: dbus, libaccountsservice0 (= 0.6.55-0ubuntu13.2), libc6 (>= 2.4), libglib2.0-0 (>= 2.44), libpolkit-gobject-1-0 (>= 0.99) Suggests: gnome-control-center Filename: pool/main/a/accountsservice/accountsservice_0.6.55-0ubuntu13.2_amd64.deb Size: 61424 MD5sum: 8d0c520e5edae8a0526a76982530ce2a SHA1: 6859166c5c490cf4be3ce74dce3816bb56d4a5f0 SHA256: 344201d66fa1327b1dfce472dc062c5eba482f4caaecb1b832ec658869660b51 SHA512: 964b9ceef71c3cb3cf88dfda3344814c19030de01a59d514268bb2fa89d6495bf9bd587a44517aa960f71b06c04550d5fe9b9cfbd83840e06179708adc4e85cf Homepage: https://www.freedesktop.org/wiki/Software/AccountsService/ Description: query and manipulate user account information Task: standard Description-md5: 8aeed0a03c7cd494f0c4b8d977483d7e Package: acct Architecture: amd64 （後略）
そしてaccountsservice_」
ここでポイントになってくるのが、
$ gpg --list-keys --keyring /etc/apt/trusted.gpg.d/ubuntu-keyring-2018-archive.gpg
/etc/apt/trusted.gpg.d/ubuntu-keyring-2018-archive.gpg
------------------------------------------------------
pub rsa4096 2018-09-17 [SC]
F6ECB3762474EDA9D21B7022871920D1991BC93C
uid [ 不明 ] Ubuntu Archive Automatic Signing Key (2018) <[email protected]>たとえばInReleaseファイルをダウンロードして検証してみましょう。
$ wget http://jp.archive.ubuntu.com/ubuntu/dists/focal/InRelease $ gpgv --keyring /etc/apt/trusted.gpg.d/ubuntu-keyring-2018-archive.gpg InRelease gpgv: 2020年04月24日 02時34分17秒 JSTに施された署名 gpgv: RSA鍵3B4FE6ACC0B21F32を使用 gpgv: 署名を検査できません: 公開鍵がありません gpgv: 2020年04月24日 02時34分17秒 JSTに施された署名 gpgv: RSA鍵871920D1991BC93Cを使用 gpgv: "Ubuntu Archive Automatic Signing Key (2018) <[email protected]>"からの正しい署名
鍵「3B4FE6ACC0B21F32」
このようにAPTによるパッケージの正当性は、
apt-keyの仕組みと問題点
apt-keyはシステム上のリポジトリ鍵を管理するコマンドです。
apt-keyコマンドはAPTキーリング/etc/）
よく紹介される例は第458回の
そんな
また、
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
これはセキュリティ上の懸念点からくるもので、
apt-key addは単一ファイル（ /etc/）apt/ trusted. gpg に鍵を追加していくため、 複数のリスクの異なるリポジトリの鍵を同じ権限で管理しなくてはならない。 - リポジトリ鍵として追加した鍵は、
すべてのリポジトリに対して適用される。
実はどちらも昔から言われていたことで、
1についてはapt-key addを使わずに、/etc/以下に個別のリポジトリ鍵を置くという回避策があります。実際、
APTのリポジトリ鍵は/etc/」
結局のところ/etc/」
現時点ではapt-keyの代替となるCLIは用意されていないようです。
今後リポジトリ鍵はどう運用すべきか
すべての利用者がサードパーティのリポジトリの利用をまったくやめることは難しいため、
まもなくリリース予定のDebian 11の2021年7月17日時点でのリリースノートでは、/etc/に個別にリポジトリ鍵を保存する方法を提案しています。apt-keyコマンドを実行したときの警告も同様です。
これはこれまでapt-key addに渡していたリポジトリ鍵を、/etc/に保存するだけというシンプルなものです。このときバイナリ形式なら拡張子
よって次のような手順で、
$ gpg --no-default-keyring --keyring /tmp/temp-keyring.gpg \
--import "ダウンロードしたリポジトリ鍵ファイル名"
$ gpg --no-default-keyring --keyring /tmp/temp-keyring.gpg \
--export --output "リポジトリ名".gpg
$ rm /tmp/temp-keyring.gpg
$ sudo cp "リポジトリ名".gpg /etc/apt/trusted.gpg.d/しかしながら、/etc/の利用も
より良い手順は、/usr/に鍵を保存しておき、sources.からリポジトリごとに参照する鍵を指定する方法です。
$ gpg --no-default-keyring --keyring /tmp/temp-keyring.gpg \
--import "ダウンロードしたリポジトリ鍵ファイル名"
$ gpg --no-default-keyring --keyring /tmp/temp-keyring.gpg \
--export --output "リポジトリ名".gpg
$ rm /tmp/temp-keyring.gpg
$ sudo mkdir -p /usr/local/share/keyrings/
$ sudo cp "リポジトリ名".gpg /usr/local/share/keyrings/ただしこれだけだとAPTからダウンロードしたリポジトリ鍵を参照できません。次にsources.に鍵を指定するオプションを付けます。おそらくサードパーティのリポジトリを導入する際には、/etc/」
変更前： deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main 変更後： deb [arch=amd64 signed-by=/usr/local/share/keyrings/"リポジトリ名".gpg] http://dl.google.com/linux/chrome/deb/ stable main
つまりdebの後ろに[signed-by=/usr/」[arch=amd64]」[]」[]」
これによりダウンロードしたリポジトリ鍵は、
おそらく当分の間、
ちなみに前述のサードパーティのリポジトリを利用することについて解説したDebian Wikiのページでは、