I did an apt update today, and was greeted with the following error messages:
ewhac@exiguous:/etc/apt$ sudo apt update
[ ... ]
Ign:12 http://dl.google.com/linux/chrome-remote-desktop/deb stable InRelease
Hit:13 https://developer.download.nvidia.com/compute/cuda/repos/debian12/x86_64 InRelease
Err:13 https://developer.download.nvidia.com/compute/cuda/repos/debian12/x86_64 InRelease
Sub-process /usr/bin/sqv returned an error code (1), error message is: Signing key on EB693B3035CD5710E231E123A4B469963BF863CC is not bound: No binding signature at time 2026-01-29T20:38:07Z because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance because: SHA1 is not considered secure since 2026-02-01T00:00:00Z
[ ... ]
Hit:21 http://dl.google.com/linux/chrome-remote-desktop/deb stable Release
3 packages can be upgraded. Run 'apt list --upgradable' to see them.
Warning: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. OpenPGP signature verification failed: https://developer.download.nvidia.com/compute/cuda/repos/debian12/x86_64 InRelease: Sub-process /usr/bin/sqv returned an error code (1), error message is: Signing key on EB693B3035CD5710E231E123A4B469963BF863CC is not bound: No binding signature at time 2026-01-29T20:38:07Z because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance because: SHA1 is not considered secure since 2026-02-01T00:00:00Z
Notice: Skipping acquire of configured file 'main/binary-i386/Packages' as repository 'http://dl.google.com/linux/chrome-remote-desktop/deb stable InRelease' doesn't support architecture 'i386'
Warning: Failed to fetch https://developer.download.nvidia.com/compute/cuda/repos/debian12/x86_64/InRelease Sub-process /usr/bin/sqv returned an error code (1), error message is: Signing key on EB693B3035CD5710E231E123A4B469963BF863CC is not bound: No binding signature at time 2026-01-29T20:38:07Z because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance because: SHA1 is not considered secure since 2026-02-01T00:00:00Z
Warning: Some index files failed to download. They have been ignored, or old ones used instead.
SHA1 was broken ages ago. As of 1 Feb 2026, Debian unstable now considers keys bearing such signatures insecure. It’s looking like a new signing key will need to be generated.
You are probably trying to install Debian-12 packages on Debian-13 (or newer), correct? (Which does make sense if you have a Pascal or Volta or Maxwell GPU). Debian-12 still accepts SHA1, so I’m not sure if NV will re-sign the whole Debian-12 repo for the sake of the unsupported use-case of adding it on newer releases :(
Because it’s not a matter of the key, but how the signature is made, ie signature algorithm/protocol version (generally you first calculate a hash of the content and then you sign just that hash, not the whole content).
Mind you, I’m not an NV employee, I’m just a rando who gave you a link with a workaround…
Except that the key itself contains a digest/hash, to ensure the key you received is itself not corrupted.
Here’s a dump of the cudatools key:
$ gpg --verbose --list-packets < cuda-archive-keyring.gpg
gpg: enabled compatibility flags:
# off=0 ctb=99 tag=6 hlen=3 plen=525
:public key packet:
version 4, algo 1, created 1649973841, expires 0
pkey[0]: BA9C999EA81C9E45E33E312CB8A5A9400829DF3A0E293B17DFAEB925771CF88EB0CE64D2B8ABC286F996D7AE474FD1EF6A4C546F67337E03A270DF249FA22297441C39976669F35018920855EB8D4EA5636364EC8BB32284B524FD2D1D6DB47BF5648EF5A63F0D546FC49E98A664F39B9442753A989B2490972EB6E7FAA709F0936E19348AEAFD9A2C19A147C551FDA489A66920EDF163706925C1E4C8F3E21B8FBD87B98F49443FFE76D5284A1EF3D37EE65A8E7A79ED3694F1510F4A473840252D25F114EFD20EA4553217201E4D1AF2BA0217EF61E4D8BB654CB19462BFB8792A37B103FD4FC04E918A82F938B76DDE4E97510BC1570250594327FFC678505ECC85FF3EFE455E422F4A35CE4D4B2A0A3EE4ADF6E646B9B996FA25222B10F51A08F10C5EEE84118F334859C2AD14BF56391FBDCF55898656CC9DFCED64E302131D4BBC1D3E67435B0D8048650FE05ADF0A2ADE4998855FE6403ACA4AA59761D0FE624795D2C75E170EDDE334AD844106E8689003BAA92C22D6AD38460DBB826C09B736E2BA09BC9B468698D39EAD7F772A32E8AE37DDA7D4D034B664F2ED84BA46A9EC8A30A358EDAD968F18519824AEE59A24FDF18A70EEB65C5F1ADDE4A3E0DCC246FF0B33A986D4E7A4CFA673FAD7711E0D7DB9F1CED1EB7B00A139ABEE558C4E37F17A65E1459B33F5688FA54F27DBB3CB00DC9D95E978EA9E4D0876A5
pkey[1]: 010001
keyid: A4B469963BF863CC
# off=528 ctb=b4 tag=13 hlen=2 plen=32
:user ID packet: "cudatools <cudatools@nvidia.com>"
# off=562 ctb=89 tag=2 hlen=3 plen=569
:signature packet: algo 1, keyid A4B469963BF863CC
version 4, created 1649973841, md5len 0, sigclass 0x13
digest algo 2, begin of digest d7 2e
hashed subpkt 2 len 4 (sig created 2022-04-14)
hashed subpkt 27 len 1 (key flags: 03)
hashed subpkt 11 len 6 (pref-sym-algos: 9 8 7 3 2 1)
hashed subpkt 21 len 5 (pref-hash-algos: 8 2 9 10 11)
hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
hashed subpkt 30 len 1 (features: 01)
hashed subpkt 23 len 1 (keyserver preferences: 80)
subpkt 16 len 8 (issuer key ID A4B469963BF863CC)
data: B2A106A4A8CEB61B7B7E3542EED2CB11D08234421A2E18848DDB1C2323E45EAF10E1E7C22147E98985931098B6A7068DC6BA8B0EDC098328C3F86028B00FC24C1227CE0462918B5B1EB6FB6D2B30CE0EB99C1AB9251C63F904D9682743BE336E1DFE307B39EB39ED2457C9F46F8D62276FC0359E667E472334780ADC5AC518298B2920D2CDE9B3A5F453EBEE55C2E7BAD045EEBF356ACB6F9554044456DC7BFE8AA872BECA3F38DD0AE16F7244A255283844CAD3A9C3DB96D5B670317B4404C80F74F4CA5134B7D1E817633E9C6A86984370C3A125FCAE6C0AE8414C46FFB4BE630FA6B44A87ACBFDDCFD88462AA1D6224A8CDF8B46FE1C5239F6C4644DF3810C1C1BDE4700444C709EF2C99AA8A3895A969282771FAEE80345C93769DE96E730F801DBF89B7D0568F2CCA5A52C50E754774689CC9127423CCAA8B7DB0F2119E5E6BB7B54E7C55626B91711769D05FB66722A5E99BEA867FAF9482916EA4C6BD8FB0D59C26879B51DCA7C8E4066D5C2932D2409E3398A7439B28E00D6DC220FADB229320883B94E26370036C10CF09E64AF3175CBA05E85B9585C000860B4CFE0A7D26B70F33DD51883C031209898BBAC816B76F84A62930ACFDA29CDA793DCF9875CCD102C6B8B37D09A72BFF507106E4FF462A7BE87DAC49827539EA524844FCC5882506CBA71523416AEFBED7FCC1352BA03F6F3678BD160DC7CAD4995139
Note in the signature packet digest algo 2. That’s SHA1, and that’s what Debian is having a problem with. The repo key needs to be regenerated and distributed.
I have same problem. extrepo still using debian 12 repo, if you are too. It has not been updated in 6 months and wouldn’t expect it until around now anyway, maybe some reason to why, debian 13 repo is made recently.
I can submit a patch to extrepo (update it to debian13) but nvidia cuda repo for debian13 contains the same SHA1 key that’s no longer valid for Trixie. We are at Nvidia’s mercy.
I am not very technical so i don’t know what that means.
Off topic, you kind of look like the Linux guy on youtube with red hat. If you are i want to thank you soo much for making video on installing nvidia drivers on Debian 13, made it so much easier to move to Linux on nvidia.
Last time i tried installing nvidia drivers though, i couldn’t select which one i wanted cause there was some dependencies error for 590.x.x when i picked 580.x.x. I could only pick nvidia-driver or nvidia-open. Obviously wanting the open one. First time i used extrepo i could select version number like example nvidia-open-580.x.x. Might be something i do wrong or something wrong with repo, thought i wanted to mention it if something wrong with repo maybe nvidia fix. This was also after i did clean driver clear/install, maybe it was the problem. sudo apt-get remove –purge ‘^nvidia-.*’
After I published that video, Nvidia released 590 drivers and with that version they also added a package called nvidia-driver-pinning-580 which you can install if you wish to remain on version 580 because you have a GPU that doesn’t support v590 or you simply prefer LTS drivers.
I will explain in non-technical way:
Debian has increased their repository security and Debian, since two days ago, requires apt repositories to have more secure signing keys
Nvidia cuda repository still uses less secure signing keys
We cannot do anything except wait. Nvidia must fix this for Debian users. Logic says that there should be a way to force APT to use lower security keys, but I did not find such option. Perhaps someone smarter than me will find it, but at the end of the day Nvidia needs to fix this.
I just tried reinstall drivers to get non beta driver, but then debian don’t allow me access repo at all. I should maybe have thought about signing keys would do this but too late now.
EDIT: After install i deleted file then disable and enable nvidia-cuda to check if it is blocked again so i don’t accidentally install anything else from a low security repo.
important to note (as I’ve already mentioned in my 1st post in this thread), that this happened only on D-13+. D-12 still accepts SHA1 and this repository, which is intended for D-12, still works fine there.
There’s a link in my first post (you must have missed it apparently), that explains how to do this.
Nvidia is unlikely to do anything, because the repo works fine on the distro they intended it for (D-12).
The proper resolution is for Debian to finally package v580 (LTS supporting everything from Maxwell to Blackwell) in D-13’s backports (trixie-backports), so that we don’t need to hack our way via the NV D-12 repos. I’ve filed a wishlist bug asking for it some time ago.
Change it in cat extrepo_nvidia-cuda.sources
Types: deb
Suites: /
Uris: Index of /compute/cuda/repos/debian13/x86_64
Architectures: amd64
Signed-By: /var/lib/extrepo/keys/8793F200.pub
This in itself is a problem. I appreciate NVIDIA wanting to reduce their maintenance burden by EOL-ing old products, and the GTX-10xx series will turn ten years old this May.
However, there are still a lot of 10xx series cards out there. Indeed, the 1080 and 1080 Ti still get a lot of love for being good performers without pulling ridiculous amounts of power.
We (probably) don’t really need drivers beyond 580. But we do need 580 to keep working through future Debian releases, particularly as Wayland finally starts to supplant X11. Debian’s non-free repo used to relegate drivers for older cards into nvidia-legacy-* packages; perhaps that’s what’s needed here.
while I do agree that it would be absolutely awesome if Nvidia added v580 to D-13 repos, I’m afraid there are little chances for it:
this is a data-center repo and nobody these days makes new Pascal/Volta DC deployments, not even Chinese, so there’s no business justification.
porting the CUDA toolkit version corresponding to v580 to glibc-2.41+ is not a completely trivial task.
Given the above, pressing Debian to finally package v580 in its repos, has much higher chances of success IMHO (especially that they can package just the driver without CUDA toolkit). I mean they have to do this at some point anyway, but if there isn’t enough pressure from the users, they will probably wait with it as one of the last steps before Forky release (so like probably late 2027 or even 2028).