Debian Buster keys expired?

I.MX6
1

I have an old cubox running the solid run buster builds. It looks like some of the apt gpg keys have expired. I get the following when I apt-get update:

# apt-get update
Hit:1 http://security.debian.org buster/updates InRelease
Hit:2 http://httpredir.debian.org/debian buster InRelease
Hit:3 http://httpredir.debian.org/debian buster-updates InRelease
Hit:4 https://repo.solid-build.xyz/debian/buster/bsp-any ./ InRelease
Hit:5 https://repo.solid-build.xyz/debian/buster/bsp-imx6 ./ InRelease
Hit:6 http://ftp.debian.org/debian buster-backports InRelease
Err:5 https://repo.solid-build.xyz/debian/buster/bsp-imx6 ./ InRelease
  The following signatures were invalid: EXPKEYSIG A86C36D7E45C02CD BSP:IMX6 OBS Project <BSP:IMX6@mxobs>
Hit:7 https://download.docker.com/linux/debian buster InRelease
Reading package lists... Done
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://repo.solid-build.xyz/debian/buster/bsp-imx6 ./ InRelease: The following signatures were invalid: EXPKEYSIG A86C36D7E45C02CD BSP:IMX6 OBS Project <BSP:IMX6@mxobs>
W: Failed to fetch https://repo.solid-build.xyz/debian/buster/bsp-imx6/./InRelease  The following signatures were invalid: EXPKEYSIG A86C36D7E45C02CD BSP:IMX6 OBS Project <BSP:IMX6@mxobs>
W: Some index files failed to download. They have been ignored, or old ones used instead.

Furthermore, it looks like a handful of keys expired yesterday?

# apt-key list | grep -A 1 expired
pub   rsa2048 2019-02-17 [SC] [expired: 2022-03-15]
      FD5A 27BB B509 878E 6DE6  2804 F74C F2AB F1A0 B0E5
uid           [ expired] BSP:8040 OBS Project <BSP:8040@mxobs>

--
pub   rsa2048 2015-08-14 [SC] [expired: 2022-03-15]
      7F6D 0395 2638 7534 04CF  A949 A86C 36D7 E45C 02CD
uid           [ expired] BSP:IMX6 OBS Project <BSP:IMX6@mxobs>

--
pub   rsa2048 2018-10-11 [SC] [expired: 2022-03-15]
      E8CA 607A 7CAD 4CFF C2E0  8A62 E15E AD09 6857 6D90
uid           [ expired] BSP:IMX8 OBS Project <BSP:IMX8@mxobs>

--
pub   rsa2048 2020-01-05 [SC] [expired: 2022-03-15]
      4120 07B5 4021 CB24 0969  4D88 4BF8 C443 814B 9D0F
uid           [ expired] BSP:LX2K OBS Project <BSP:LX2K@mxobs>

I’ve tried installing the keys from here: pkg-solidrun-keyring/active-keys at master · SolidRun/pkg-solidrun-keyring · GitHub

But that doesn’t seem to fix the issue. I think the apt repo is signed with the expired key. Is there an apt repo that is signed with the updated v2 key in the above github repo?

1 Like
2

I have pinged our Debian package maintainer. They will get back to you shortly.

3

\o/

You are correct in your findings, the signing key has expired.
I can assure you that you are not losing out on any updates, as there are none.

However we are currently transitioning our infrastructure targeting Debian to a new solution, and will provide new repositories as new images are going to be available.

1 Like
4

Hi all, is their any update to when this will be fixed?

5

I have this same issue.

6

This issue means “apt-get upgrade” fails before other installed packages upgrade. The only workaround I’ve found is to individually update other packages with "sudo apt-get install --only-upgrade ".

This is a pain for your customers, that can’t be that hard to fix.

7

Still not updated :upside_down_face:

8

This is still an issue. Given that Debian 12 / Bookworm has been released, are there any plans for ever fixing this?

Also, are Bookworm builds planned? Index of /debian/ still only goes up to Bullseye.

9

Not sure if it was ever written here, but I just discovered there is a new keyring package, version 2022.07.04 that seems to fix this. But it fails to update because the old key is invalid. The easiest solution appears to be a temporary change to the sources list. For each of the solidrun repos, add:

deb [ allow-insecure=yes ] https://repo.solid-build.xyz/debian/bullseye/bsp-any ./

Add the thing between square brackets. Now just do a regular update/upgrade and it will install the new key package. After that you can remove the allow-insecure again.

1 Like