Tin*_*ino 7 apt keyrings 20.04
# apt-get update
Hit:1 http://security.ubuntu.com/ubuntu focal-security InRelease
Ign:2 http://ddebs.ubuntu.com focal InRelease
Hit:3 http://dl.google.com/linux/chrome/deb stable InRelease
Hit:4 http://packages.microsoft.com/repos/code stable InRelease
Hit:5 http://de.archive.ubuntu.com/ubuntu focal InRelease
Ign:6 http://ddebs.ubuntu.com focal-updates InRelease
Ign:7 https://apache.bintray.com/couchdb-deb focal InRelease
Hit:8 http://de.archive.ubuntu.com/ubuntu focal-updates InRelease
Get:9 https://apache.bintray.com/couchdb-deb focal Release [1838 B]
Ign:10 http://ddebs.ubuntu.com focal-proposed InRelease
Hit:11 http://de.archive.ubuntu.com/ubuntu focal-backports InRelease
Hit:12 http://ddebs.ubuntu.com focal Release
Hit:13 http://ddebs.ubuntu.com focal-proposed Release
Get:14 http://ddebs.ubuntu.com focal-updates Release [40.5 kB]
Get:15 http://ddebs.ubuntu.com focal-updates Release.gpg [819 B]
Err:17 http://ddebs.ubuntu.com focal Release.gpg
The following signatures were invalid: EXPKEYSIG C8CAB6595FDFF622 Ubuntu Debug Symbol Archive Automatic Signing Key (2016) <ubuntu-archive@lists.ubuntu.com>
Err:18 http://ddebs.ubuntu.com focal-proposed Release.gpg
The following signatures were invalid: EXPKEYSIG C8CAB6595FDFF622 Ubuntu Debug Symbol Archive Automatic Signing Key (2016) <ubuntu-archive@lists.ubuntu.com>
Err:15 http://ddebs.ubuntu.com focal-updates Release.gpg
The following signatures were invalid: EXPKEYSIG C8CAB6595FDFF622 Ubuntu Debug Symbol Archive Automatic Signing Key (2016) <ubuntu-archive@lists.ubuntu.com>
Fetched 43.1 kB in 2s (27.1 kB/s)
Reading package lists... Done
（请忽略上面的非 Ubuntu 存储库。它们不是问题的一部分。）
前几天一切正常，但突然，不知从何而来，上面发生了。
请注意，从密钥服务器下载密钥或任何类似的不安全活动都不是答案，而是问题本身。
因此，一个适当的可接受的答案必须包括一种方法来（加密地）验证它是合法的，并且失败（然后修复）存储库的发起者确实是 Canonical 而不是能够充当假 Ubuntu 镜像、密钥服务器的其他人或 MitM（可能带有来自某些受损 CA 的合法 SSL 证书）。
它必须能够在未经修改、真实且脱机的 Ubuntu 20.04 LTS 上重现解决方案，该 LTS 只能访问一些本地未经验证的 Ubuntu 镜像（因此它也必须验证镜像的真实性）。
解决方案不得包括时间失真（机器必须与 NTP 同步），也不得在全局范围内关闭某些安全功能（例如禁用对过期密钥的 apt 检查）。
然而，解决方案可以包括允许继续使用过期密钥的本地修改，只要这不影响机器上的任何其他密钥，例如手动延长 key 的生命周期C8CAB6595FDFF622，但仅限于这个孤独的密钥。
# apt-get install ubuntu-dbgsym-keyring
Reading package lists... Done
Building dependency tree
Reading state information... Done
ubuntu-dbgsym-keyring is already the newest version (2020.02.11.2).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
# dpkg -L ubuntu-dbgsym-keyring
/.
/etc
/etc/apt
/etc/apt/trusted.gpg.d
/etc/apt/trusted.gpg.d/ubuntu-keyring-2016-dbgsym.gpg
/usr
/usr/share
/usr/share/doc
/usr/share/doc/ubuntu-dbgsym-keyring
/usr/share/doc/ubuntu-dbgsym-keyring/changelog.gz
/usr/share/doc/ubuntu-dbgsym-keyring/copyright
/usr/share/keyrings
/usr/share/keyrings/ubuntu-dbgsym-keyring.gpg
/usr/share/keyrings/ubuntu-dbgsym-removed-keys.gpg
（WTF为什么/.？！？）
# apt-key list C8CAB6595FDFF622
pub rsa4096 2016-03-21 [SC] [expired: 2021-03-20]
F2ED C64D C5AE E1F6 B9C6 21F0 C8CA B659 5FDF F622
uid [ expired] Ubuntu Debug Symbol Archive Automatic Signing Key (2016) <ubuntu-archive@lists.ubuntu.com>
expired解释为什么apt呻吟。但知道这一点并没有给我一个解决方案，只是提出了问题。
一旦 Canonical 发布更新到ubuntu-dbgsym-keyring. 但是在那之前，只要缺少这一点，就必须有某种方法如何使用某种回退方法自己正确处理这样的问题，对吗？由于过期的密钥材料是一个常见问题，而不是说密码学中最常见的标准问题之一，对吗？
所以密钥过期不是 Canonical 的错。Tempus fugit 和每个处理密码标准的人都知道这一点。由于这是处理加密时的标准问题，因此处理这种情况肯定是每个加密标准的一部分，对吗？因此，每个正确的 Crypto 实现都必须提供一些简单的方法来解决这些基本的标准问题，通过提供一个本地临时解决方案，当不再需要它时会自动解决，对吗？
DES 发明于 1975 年，现在已经是 2021 年了。因此密码学当然是成熟的，并且不缺乏像处理过期密钥这样的基本标准模式，对吗？而且这只是我自己的错，不知道如何正确处理这样一个标准问题，对吧？还是我在这里完全错了？
（免责声明：这个问题中的一切都是诚实的，不包括讽刺。所有的讽刺都在那里。）
https://bugs.launchpad.net/ubuntu/+source/ubuntu-keyring/+bug/1920640/comments/32提供的解决方案对我有用：
sudo apt remove --purge ubuntu-dbgsym-keyring
sudo apt-key del 0xC8CAB6595FDFF622
sudo apt install ubuntu-dbgsym-keyring
| 归档时间： |
|
| 查看次数： |
1988 次 |
| 最近记录： |