Skip to content

Packages can fail to build due to expired signing keys in old keyrings #87

Closed
@fergus-dall

Description

@fergus-dall

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:

  1. Steal developer signing key
  2. Sign a compromised version of gcc at some old version which introduces a flaw into some other package
  3. Push compromised gcc to package archive
  4. Build compromised package using compromised gcc
  5. Publish compromised package
  6. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions