web-dev-qa-db-ja.com

なぜこれが発生するのですかAPT警告:キーによる署名[...]は弱いダイジェストアルゴリズム(SHA1)を使用しますか?

私はいくつかのカスタムRaspberryPiコード用のプライベートDebianリポジトリをホストしています。私は最初にRaspbian Jessie(バージョン8)でソフトウェアを構築し、リポジトリへの署名に使用するGPGキーを生成し、すべてのデバイスでSudo apt-key add ...を実行して、リポジトリが確実に認証されるようにしました。最近、Raspbian Stretch(バージョン9)を実行するいくつかの新しいデバイスを追加するまで、これは正常に機能しました。まったく同じGPGキーを追加しましたが、Sudo apt-get updateを実行したときに表示される出力は次のとおりです。

W: GPG error: http://url.of.private.repo stable Release: The following signatures were invalid: 95F9B44CE35F40B759D59C2A77E4184C595493B1
W: The repository 'http://url.of.private.repo stable Release' is not signed.
N: Data from such a repository can't be authenticated and is therefore potentially dangerous to use.
N: See apt-secure(8) manpage for repository creation and user configuration details.

ただし、これは新しいボックスでのみ発生します。まだJessieを実行しているPisで、必要なすべてをSudo apt-get update実行できますが、認証の警告は表示されません。

それらがすべて同じキーを共有しているにもかかわらず、Stretchを実行しているPisがGPGキーが無効であると考えるのはなぜですか? Stretchを実行しているボックスで新しいキーを生成することはできますが、すべてのJessieボックスに新しいGPGキーを追加することは避けたいと思っています。 (現在、Stretchを実行している新しいボックスはほんの一握りですが、Jessieを実行しているボックスは約200です。)このGPGキーが実際に有効であることをStretchボックスに納得させるにはどうすればよいですか?

リクエストに応じて、以下は両方のプラットフォームでのSudo apt-get -o Debug::Acquire::gpgv=true updateコマンドの出力です。

5
soapergem

コメントの通り:

_SHA1_は弱いと想定されているため、Debianは 2016年3月 に戻ってより強力なハッシュアルゴリズムに切り替えることを決定しました。

したがって、APTリポジトリを操作している場合:_SHA1_を非推奨にし、(少なくとも)_SHA256_に切り替えます。

推論に関する要約については このDebian wiki記事 および壊れた/修正された(上流)リポジトリを追跡する これ を参照してください。

2
gf_

これ 質問ubuntuの答え 私のためにそれを修正しました:編集~/gnupg/gpg.confそして追加:

cert-digest-algo SHA256
digest-algo SHA256
0
Michel