検証パッケージ

画像の内容は、PGPキーを使用して直接または間接的に署名されます。 Debianディストリビューションの「root」から始めます。

• Release、独立した署名で署名Release.gpg、すべてのパッケージインデックスのハッシュ（MD5、SHA1、SHA256）とインストーラハッシュ（InRelease今2つを組み合わせてください）。
• パッケージインデックス（例えば、binary-amd64）にはパケットのハッシュ（MD5およびSHA256）が含まれています。

ハッシュと署名は、apt-getシステム（管理apt-key）に保存されているPGPキーなどのツールを使用して確認されます。したがって、受信システムが正常な場合、デフォルトではアーカイブのPGPキーで（間接的に）署名しない限り、Debianアーカイブからどのパッケージもインストールできません。画像の侵入者が関連するPGPキーを制御しない場合、バイナリを交換することはできません。

制御ミラー

これは、アーカイブを破損するだけでは、エンドユーザーシステムを実際に破損させるのに十分ではなく、そのシステムがすでに信頼しているPGPキーも破損する必要があることを意味します。 （結果的にDebianシステムにキーを追加することは軽く受け入れられません。）アーカイブのセキュリティはそれほど重要ではないので、これは最初の問題をある程度解決します。しかし、重要なシステム（署名が発生する場所）は厳密に監視され監督され、それにアクセスできる人はほとんどいません。

メンテナンス者の期待

パッケージが「実際にメンテナンス者が考えているのと同じ」ことを保証するには、より多くの参加が必要です。パッケージが使用するパスは次のとおりです。

• パッケージは管理者によって準備され、Debian キーリング（つまりアップロードされた Debian 開発者または Debian 管理者に属するキー、Debian キーリングサーバーにアップロードされ、キーリングメンテナンスチームによってマージされます。
• 署名されたパッケージはアーカイブにアップロードされ、確認されます（何よりも使用されているキーは現在のキーリングに存在し、期限切れにならず、署名が有効でなければならず、DMがパッケージに署名した場合、DMにはパッケージに対する関連権限が必要です。します。
• アップロードされたバイナリはすべてそのまま最終アーカイブにプッシュされます（ここでは少し単純化しましたが、これは効果です）。
• 不足しているバイナリの原因は次のとおりです。立てるビルドのPGPキーで署名し、最終アーカイブにプッシュされます（どのビルドキーが有効であるかを知り、そのキーと比較してファイルを確認します）。
• これらすべての更新は最終的に適切なインデックス更新（上記のように署名されている）を使用してミラーネットワークにプッシュされます。

管理者がパッケージソースと共にバイナリをアップロードすると、これらのファイルは最終的に（現時点では）提供されます。バイナリのアップロードはオプションですので、スキップすることはますます一般化され、最終的にアップロードされたバイナリは削除されます。 （Ubuntuでは常にそうでした）他のバイナリが管理者の期待を満たすかどうかは、構築されたネットワークによって異なります。したがって、建物も厳密に監督され、ほとんどアクセスされない重要なシステムです。すべての成果物が署名されているため、ファイルの整合性を常に確認できます。まず、管理者のキー、次にビルドされたキー、最後にアーカイブされたキーについて確認できます。

元の署名は画像では使用できず、すべてのDDは不足しているバイナリをアップロードできます。しかし、Debian 11以降、アーカイブのすべての新しいバイナリはビルドデーモンで提供されます。 DDからアップロードされたバイナリは、不安定、実験的、またはバックポートされたリポジトリでのみ使用できます。元の署名は以下から取得できます。Debian - 開発 - 変更ファイル。

要するに現在、システムは完璧ではありませんが、ミラーからダウンロードできるすべてのファイルのトレーサビリティを提供します。このような状況を改善するための多くの努力があります。繰り返し可能なビルド（これにより、公開されたソースとバイナリが一致するかどうかを独立して確認できます）、管理者が提供したバイナリを削除します。