Description
I recently set up a rebuilderd instance running on archlinux core, and discovered 54 packages fail to build because one or more of the packages in their build environment fails the GPG signature check. All the packages failing validation have valid signatures from the perspective of the current archlinux-keyring package, but in the old archlinux-keyring packages used in the builds, the signing keys have expired.
Specifically, the following two keys:
60411304C09D36628340EEFFCEB167EFB5722BD6 (eschwartz) expired on 2020-10-17, extended to 2022-07-10 in keyring version 20200817
E550FFFFD485E264A1717E30901C1C320EB0D45D (demize) expired on 2020-12-10, extended to 2022-02-03 in keyring version 20200422
Signed the following five packages:
asciidoc 9.0.2-1 (eschwartz)
autoconf-archive 1:2019.01.06-1 (eschwartz)
ncompress 4.2.4.6-1 (eschwartz)
pkgconf 1.6.3-2 (demize)
python2-typing 3.6.6-1 (demize)
Which are used along with pre-extension archlinux-keyring versions in the builds of the following packages:
automake 1.16.2-3
b43-fwcutter 019-3
base 2-2
ca-certificates 20181109-4
ca-certificates-utils 20181109-4
cracklib 2.9.7-2
crda 4.14-3
cronie 1.5.5-1
db 5.3.28-5
dbus 1.12.20-1
dbus-docs 1.12.20-1
diffutils 3.7-3
ding-libs 0.6.1-3
dmraid 1.0.0.rc16.3-12
dosfstools 4.1-3
findutils 4.7.0-2
flex 2.6.4-3
gdbm 1.18.1-3
gzip 1.10-3
hdparm 9.58-3
ifenslave 1.1.0-11
inetutils 1.9.4-8
ipw2100-fw 1.3-10
ipw2200-fw 3.1-8
jfsutils 1.1.15-7
ldns 1.7.1-2
libaio 0.3.112-2
libgssglue 0.4-4
libmnl 1.0.4-3
libmpc 1.1.0-2
libnl 3.5.0-2
libssh2 1.9.0-2
lzo 2.10-3
m4 1.4.18-3
minizip 1:1.2.11-4
mkinitcpio-nfs-utils 0.3-7
net-tools 1.60.20181103git-2
nilfs-utils 2.2.8-2
npth 1.6-2
patch 2.7.6-8
pinentry 1.1.0-5
pptpclient 1.10.0-2
procinfo-ng 2.0.304-8
psmisc 23.3-2
pth 2.0.7-7
reiserfsprogs 3.6.27-3
rpcbind 1.2.5-3
run-parts 4.8.6.1-2
sysfsutils 2.1.0-11
tar 1.32-3
vi 1:070224-4
which 2.21-5
wireless_tools 30.pre9-3
zlib 1:1.2.11-4
These packages don't appear broken on reproducible.archlinux.org because this issue only affects packages that were built before the developer in question updated their archlinux-keyring package to a version that includes the relevant key extension(s), that were rebuilt after the expiry. Assuming developers update reasonably frequently, that reproducible.archlinux.org rebuilds packages shortly after they are published, and that it doesn't rebuild packages after it gets a successful repro, all of these packages would have been checked within the remaining validity of the signing keys.
A related issue is that we ignore any key revocations that weren't in effect at the time the package was published. If you're hoping to get a chain of trust stretching from newer packages back to older packages, then the compromise of a signing key for an old package is a big problem. There's a compromise path like:
- Steal developer signing key
- Sign a compromised version of gcc at some old version which introduces a flaw into some other package
- Push compromised gcc to package archive
- Build compromised package using compromised gcc
- Publish compromised package
- The bad gcc is never checked, because it looks like an out-of-date package, and the new package reproduces because reproducers will use the bad gcc package, even if the signing key is later revoked
Always using the newest archlinux-keyring package would solve both of these issues, though it's still not clear to me how to recover from a compromised developer signing key.