☰

/etc/apt/sources.list.d/で構成されている一部のリポジトリにsigned-by =が設定されていないのはなぜですか？ - それは問題ですか？

tag-icon • tag-icon debian apt security postgresql
/etc/apt/sources.list.d/で構成されている一部のリポジトリにsigned-by =が設定されていないのはなぜですか？ - それは問題ですか？

設定されたサードパーティのほとんどのストレージには、/etc/apt/sources.list.d次のように設定された署名キーがありますdeb [signed-by=/etc/apt/keyrings/lutris.gpg] https://。

ただし、postgresqlなどの一部のシステムにはこの設定はありません。それは問題ですか？これが問題になることがありますが、必ずしも問題になるわけではない場合、これが存在するかどうかを確認できますか？具体的には、postgresqlリポジトリにはリポジトリ署名キーがあります。しかし、なぜそこに指定する必要はありませんか？

また、Linuxダウンロードページで実行されているデータベースでこれらの手順を実行するとき

wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -それは言ったWarning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).

ランタイムsudo apt-get update出力には以下が含まれます。

幅：https://apt.postgresql.org/pub/repos/apt/dists/bookworm-pgdg/InRelease：キーは既存のtrusted.gpgキーリング（/etc/apt/trusted.gpg）に保存されます。詳細については、apt-key(8) のサポート終了を参照してください。 N：設定ファイル「main/binary-i386/Packages」をリポジトリ「https://apt.postgresql.org/pub/repos/apt bookworm-pgdg InRelease」にインポートすることをスキップすることは、アーキテクチャ「i386」をサポートしませんではありません。

  • 後者の問題はファイルを編集することでkwrite /etc/apt/sources.list.d/pgdg.list解決できますが、deb [arch=amd64] https:...これは必須ではありません（設定はそのまま機能する必要があります）。
  • for ...これにより、長いコマンドを使用して解決できる従来のtrust.gpgキーリングの問題のみが残ります。ここ（これは必ずしも必須ではありません。デフォルトで、またはユーザーにメッセージを表示した後に自動的にキーをインポートし、少なくともダウンロードページの指示が最新でないことを確認してください。）
  • これがすべて完了したら、残りの質問は、pgdg.listファイルに署名キーが指定されていないことが問題ではないかどうかです。ダウンロードページも更新する必要があります。

答え1

考慮すべき4つのことがあります。

  1. についてsigned-by（に記録man 5 sources.list、その目的は、特定のリポジトリから提供されるパッケージが特定のキーリングのキーまたは特定のキーで署名されるようにすることです。そのエントリを持たないリポジトリが破損し、APTキーリングの他のキーで署名されたパッケージの配送を開始すると、エラーは発生しません。

    セキュリティの面では大きな違いはないと思います。ストレージ署名キーが漏洩した場合、署名したいストアは破損したパッケージを送信するために非常にうまく使用できます。破損したキーの機能を追加して他のリポジトリのパッケージに署名することは大幅に増加しないようです。攻撃面。主な例外はAPTキーリングに追加されて忘れられたキーですが、答えはAPTキーリングの使用を中止することです。

    私にとっての主な用途はsigned-by文書化です。どのキーがどこで使用されているかを記録します。これは、関連付けられたリポジトリが削除されたときに管理者がキーを削除するのに役立ちます。

    APTリポジトリの主な弱点は、同じ名前空間を共有することです。したがって、感染したAPTリポジトリは、libc6Debianのバージョンよりも新しいバージョンの感染パッケージを公開でき、そのAPTリポジトリを使用するシステムはそのパッケージにアップグレードされます。システム管理者にとって、最善の防御は、サードパーティとサードパーティのキーの使用を制限することです。すべての人のための状況を改善するには、Debian側で多くの作業が必要になるでしょう（パッケージがどこから来たのかを覚えていて、リポジトリが変更されたときに警告するような「簡単な」ソリューションですが、Debian自体は少なくとも2つの異なるリポジトリです。バージョンには最大4つのリポジトリがあり、現在第三者リポジトリがDebianを偽装するのを防ぐ方法はありません（使用されているキーを除く）。Debianソフトウェアパッケージの信頼性をどのように保証しますか？

  2. サポートの中止に関してapt-key、「未使用」セクションman 8 apt-keywgetに依存しないようにコマンドラインを変換する方法を正確に説明しますapt-key。

  3. そのi386通知（完全に無害です）に関してはそうです。 PostgreSQLストレージディレクティブ（上記の変更とともに）を理想的に更新する必要があります。

  4. 上記はPostgreSQLに限定されず、特にPostgreSQLに関するものです。サードパーティのリポジトリを使用するのはなぜですか？ Debian 12 には、上流の PostgreSQL リポジトリで利用可能な最新バージョンと同じ PostgreSQL 15.6 が含まれています。 （以前のバージョンを使用する必要がありますか？）

関連情報