Ubuntu 24.04 complains about unknown key used for signature on apt.kitware.com ...

Site Feedback
1

W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: ``https://apt.kitware.com/ubuntu`` noble InRelease: The following signatures couldn’t be veri
fied because the public key is not available: NO_PUBKEY 65ADECD7A7039392
W: Failed to fetch ``https://apt.kitware.com/ubuntu/dists/noble/InRelease`` The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY 65ADECD7A7039392
W: Some index files failed to download. They have been ignored, or old ones used instead.

Any ideas what’s going on? Where should this be reported if not here?

PS: yes, I do have the kitware-archive-keyring package installed and my last update and/or upgrade was in early December 2025.

2

Just saw on hour CI that the provisioning step for our containers fails for the same reason (since January 8th).

Edit #1: sent an email to the email address mentioned on the apt.kitware.com index page.

3

Well, I guess that explains it:

$ curl -I https://apt.kitware.com/keys/kitware-archive-latest.asc
HTTP/1.1 200 OK
Date: Mon, 12 Jan 2026 13:30:12 GMT
Server: Apache
Strict-Transport-Security: max-age=15552000; includeSubDomains
Last-Modified: Mon, 05 Jan 2026 21:54:22 GMT
ETag: "f7b-647ab1a170db8"
Accept-Ranges: bytes
Content-Length: 3963
X-Frame-Options: sameorigin
Content-Type: application/pgp-keys

Last-Modified: Mon, 05 Jan 2026 21:54:22 GMT

Doesn’t explain, though, why the new key wasn’t advertised ahead of time through kitware-archive-keyring or — assuming the old key expired — why it wasn’t prolonged (a best practice with PGP keys). The expiry is meant for the case that you get incapacitated to prolong the validity or lose access (in absence of a revocation key).

Edit #1:

$ mkdir /tmp/gnupg-temp; chmod 700 /tmp/gnupg-temp
$ export GNUPGHOME=/tmp/gnupg-temp
$ curl -sfLo - https://apt.kitware.com/keys/kitware-archive-latest.asc|gpg --import
gpg: keybox '/tmp/gnupg-temp/pubring.kbx' created
gpg: /tmp/gnupg-temp/trustdb.gpg: trustdb created
gpg: key 9E92FDC6C5B9BA75: public key "Kitware Apt Archive Automatic Signing Key (2026) <debian@kitware.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1
$ gpg --list-keys --with-fingerprint
/tmp/gnupg-temp/pubring.kbx
---------------------------
pub   rsa4096 2025-06-23 [SC] [expires: 2028-06-22]
      4DBE BE3E EC96 E7B8 C6EC  5BE9 9E92 FDC6 C5B9 BA75
uid           [ unknown] Kitware Apt Archive Automatic Signing Key (2026) <debian@kitware.com>
sub   rsa4096 2025-06-23 [S] [expires: 2028-06-22]

Hmm, weird. So apparently this was willingly done but shouldn’t I have had this then through the kitware-archive-keyring package?

Edit #2:

$ dpkg -l|grep kitware-archive-keyring
ii  kitware-archive-keyring               2025.06.23                                                       all          Kitware apt archive keyring

Coincidentally — well, I think probably not — the same date as the subkey shown by GnuPG above.

Still digging a little to put the puzzle pieces together.

4

deb [arch=amd64 signed-by=/usr/share/keyrings/kitware-archive-keyring.asc] ... was the issue. The file created by current versions of the upstream script and the instructions shown on apt.kitware.com are .gpg, not .asc.

Or in other words: apologies for the noise.