Broken APT-Cacher Update

whoami · February 15, 2025, 4:33pm

My system configuration

debian-12-minimal (freshly installed)
using apt-cacher
double checked all apt-cacher configurations

It worked fine before, I don’t know what I did but every apt update ends with the following error message now.

sudo apt update
Hit:1 http://HTTPS///deb.debian.org/debian bookworm InRelease
Get:2 http://HTTPS///deb.debian.org/debian-security bookworm-security InRelease [48.0 kB]
Hit:3 http://HTTPS///deb.qubes-os.org/r4.2/vm bookworm InRelease
Err:2 http://HTTPS///deb.debian.org/debian-security bookworm-security InRelease
  The following signatures were invalid: BADSIG 54404762BBB6E853 Debian Security Archive Automatic Signing Key (11/bullseye) <ftpmaster@debian.org>
Fetched 48.0 kB in 0s (105 kB/s)
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: http://HTTPS///deb.debian.org/debian-security bookworm-security InRelease: The following signatures were invalid: BADSIG 54404762BBB6E853 Debian Security Archive Automatic Signing Key (11/bullseye) <ftpmaster@debian.org>
E: Failed to fetch http://HTTPS///deb.debian.org/debian-security/dists/bookworm-security/InRelease  The following signatures were invalid: BADSIG 54404762BBB6E853 Debian Security Archive Automatic Signing Key (11/bullseye) <ftpmaster@debian.org>
E: Some index files failed to download. They have been ignored, or old ones used instead.

It points to an issue related to bullseye (Debian 11)?

I checked the trusted keys:

ls /etc/apt/trusted.gpg.d/
total size of directory: 88K	.
drwxr-xr-x. 2 root root 4.0K 2024-09-07 10:10 .
drwxr-xr-x. 8 root root 4.0K 2025-01-05 10:53 ..
-rw-r--r--. 1 root root  12K 2023-07-30 21:30 debian-archive-bookworm-automatic.asc
-rw-r--r--. 1 root root  12K 2023-07-30 21:30 debian-archive-bookworm-security-automatic.asc
-rw-r--r--. 1 root root  461 2023-07-30 21:30 debian-archive-bookworm-stable.asc
-rw-r--r--. 1 root root  12K 2023-07-30 21:30 debian-archive-bullseye-automatic.asc
-rw-r--r--. 1 root root  12K 2023-07-30 21:30 debian-archive-bullseye-security-automatic.asc
-rw-r--r--. 1 root root 3.4K 2023-07-30 21:30 debian-archive-bullseye-stable.asc
-rw-r--r--. 1 root root  11K 2023-07-30 21:30 debian-archive-buster-automatic.asc
-rw-r--r--. 1 root root  11K 2023-07-30 21:30 debian-archive-buster-security-automatic.asc
-rw-r--r--. 1 root root 1.7K 2023-07-30 21:30 debian-archive-buster-stable.asc

cat /etc/apt/sources.list
deb http://HTTPS///deb.debian.org/debian bookworm main contrib non-free-firmware
#deb-src http://HTTPS///deb.debian.org/debian bookworm main contrib non-free-firmware

deb http://HTTPS///deb.debian.org/debian-security bookworm-security main contrib non-free-firmware
#deb-src http://HTTPS///deb.debian.org/debian-security bookworm-security main contrib non-free-firmware

whoami · February 17, 2025, 6:24am

Anyone can help here?
… if not I need to do a re-installation.

alimirjamali · February 17, 2025, 7:34am

Not a apt-cacher user here.

I believe you could temporarily change http://HTTPS/// and replace it with https:// in /etc/apt/sources.list file. This should allow you to update as usual but you will lose caching. Then wait for unman or others who are apt-cacher expert to advise.

whoami · February 17, 2025, 7:57am

Confirmed, switching back to non-apt-cacher configuration, fixed the key issue.
Thank you!

Still wondering what causes this bullseye key issue (with the apt-cacher).

whoami · February 17, 2025, 8:59am

… I wouldn’t label it solution but I need it fixed quickly.
Therefore, I used the hammer approach*: removed and recreated the apt-cacher.
It fixed the bullseye key issue.

* Thanks to my automated script, apt-cacher creation and 30+ templateVM reconfiguration and update was done in a few minutes .

fb2043 · February 20, 2026, 10:53am

Just had the same error.

What it means is that the InRelease file downloaded from the bookworm-security repo is not getting verified successfully by the public key in apt’s keyring.

To confirm this, you can go in /var/cache/apt-cacher-ng/deb.debian.org/debian-security/dists/bookworm-security where you will find an InRelease file and possibly multiple InRelease.[timestamp] files which represent older caches.

If you inspect their contents, you will find that they are PGP-signed. You can manually try to see if they are verified by the public keys in apt’s keyring:

gpg --keyring /usr/share/keyrings/debian-archive-bookworm-security-automatic.gpg --verify InRelease

It will probably fail. You can similarly try to use the debian-archive-bullseye-security-automatic.gpg public key (debian 12 InRelease files seem to be signed with both bookworm and bullseye keys). You can also try to verify older InRelease.[timestamp] files if you have any, and those should probably work.

But that doesn’t explain why this is happening. In my case, I happened to have an InRelease.[timestamp] file which was only a day older than the one which was failing verification. So I expected their content to be very similar. I ran the following command:

sdiff -s InRelease InRelease.[timestamp]

to check for any differences in their contents. Surprisingly, the only difference was in the lines for Date: and Valid-Until:. That means that the PGP signature at the bottom of each file was also identical.

This doesn’t really make sense, because the PGP signature is a hash generated using the contents of the files and therefore should have changed (i.e a new one generated) if the contents were different. It looks almost as if the Date: and Valid-Until: lines were edited manually in the old version, and everything else left the same. I don’t really know how this was possible, so curious to hear if anyone else can chime in.

The problem was easy to solve by removing the InRelease file. So on the next apt update run, a new one was downloaded. The new one has the same contents as the one which was failing verification (including the same Date: and Valid-Until: lines), except that the PGP signature at the bottom is different this time (and can be verified successfully).

unman · February 20, 2026, 12:46pm

Thanks @fb2043 - this really shouldnt happen and indicates an error at
the repository. You some times see this, but it’s always caught by the
PGP checks.
It shouldnt be necessary to manually clear the InRelease file as the
cacher will reap them in good time, but it cant do any harm.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.