debian – 为什么我会收到此APT警告:按键[…]签名使用弱摘要算法(SHA1)?

前端之家收集整理的这篇文章主要介绍了debian – 为什么我会收到此APT警告:按键[…]签名使用弱摘要算法(SHA1)?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我正在为一些自定义Raspberry Pi代码托管私有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的新盒子,而大约200个盒子仍在运行Jessie.)我能说服Stretch盒子这个GPG键实际上是否有效?

根据要求,以下是两个平台上sudo apt-get -o Debug :: Acquire :: gpgv = true update命令的输出

> Jessie debug output
> Stretch debug output

解决方法

根据评论

假设SHA1很弱,因此Debian决定在March 2016年重新使用更强的哈希算法.

因此,如果运行APT存储库:弃用SHA1并切换(至少)到SHA256.

有关推理的摘要,请参阅this Debian wiki article;有关跟踪已损坏/固定(上游)存储库的this one,请参阅this one.

原文链接:/linux/396489.html

猜你在找的Linux相关文章