Signature verification for Repository NVIDIA:repo-non-free failed

Hi, I installed 15.6 with the NVIDIA driver a few days ago and have not had any problems, but today I got the following error

Update Error
Signature verification for Repository NVIDIA:repo-non-free failed

The repo according to zypper is :

Has anybody else seen this?
I noted that the date of the files in that repo have all today’s date.
What do you do in such situations?
Wait a few days and hope it will be resolved?

There is an update to the signing key. See the linked news post at New signing key for NVIDIA repositories - #3 for details.

Oh, thank you, I have not seen that news.

1 Like

This solution does not really work for me, because I received a new nvidia signing key and fingerprint TODAY that DIFFERS from the announced key and finderprint when I updated the nvidia signing key for Leap 15.6.
(I was asked to do so by yast2 when I refreshed the${releasever} repository, where ${releasever} equals 15.6.)
Compare for yourself:
key - fingerprint:
B1D0D788DB27FD5A - 2FB03195DECD49492BD1C17AB1D0D788DB27FD5A (announced)
F5113243C66B6EAE - 9B763D49D8A5C892FC178BACF5113243C66B6EAE (actually received today)
The key I received seems to work, but it is not the announced one. Can anybody explain this, or has anybody experienced the same? Should this key be relied upon?

I just pulled the repomod.xml.key file from that URL (replacing the version variable with 15.6) and here’s what gpg reports about it:

$ gpg --list-packets repomd.xml.key 
# off=0 ctb=99 tag=6 hlen=3 plen=525
:public key packet:
	version 4, algo 1, created 1649973841, expires 0
	pkey[0]: [4096 bits]
	pkey[1]: [17 bits]
	keyid: B1D0D788DB27FD5A
# off=528 ctb=b4 tag=13 hlen=2 plen=48
:user ID packet: "NVIDIA Linux Driver Team <>"
# off=578 ctb=89 tag=2 hlen=3 plen=569
:signature packet: algo 1, keyid B1D0D788DB27FD5A
	version 4, created 1649973841, md5len 0, sigclass 0x13
	digest algo 2, begin of digest c9 fd
	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 B1D0D788DB27FD5A)
	data: [4095 bits]

This shows the announced key and not the one you indicated you received.

ETA: Here’s the fingerprint info as well:

$ gpg --show-keys --with-fingerprint repomd.xml.key
pub   rsa4096 2022-04-14 [SC]
      2FB0 3195 DECD 4949 2BD1  C17A B1D0 D788 DB27 FD5A
uid                      NVIDIA Linux Driver Team <>

Thank you.

I can now reproduce what made me doubt. When I updated the nvidia repo, I accepted and imported the new key and fingerprint. And I assumed (not quite irrationally, I would say) that I had thereby replaced the old key by the new one. This was, however, apparently not the case, because yast2 still showed only the old key, not the new one. (I would count that as a bug.) Even after closing yast2 and reopening it, yast2 still showed the old key as valid, but this time also the new key, which was then overlooked by me.

So, the fact that yast2 only showed the imported new key after closing and reopening yast2, and even then kept the old key without showing it as invalid, had made me overlook the new key.

I think that yast2 should have handled this better, but my problem is solved and I feel reassured.

1 Like

Sounds like something you should submit to so someone can take a look at it.

The old key is not retracted. It is still valid but no longer used for signing of packages. That is why both keys show up in YaST.

1 Like

Yes, but does that make sense?
And why does yast2 not show the newly imported key immediately? This is why I thought the old key was the newly imported key. And since the old key differed from the announced new one, I thought the newly imported key differed from the announced one.
Only after closing and reopening yast2, I realised there now were 2 keys, the old one and the new one, but the old one as valid as the new one, though apparently useless.

Too much other stuff to do, unfortunately. Besides, it might not even count as a true bug. More like something unergonomic, but still tolerable. User interface standards are fairly low, undeservedly to my mind.

I experienced the same thing today. Sorry for the simplistic question:
In Yast, under Software Repositories, GPG Keys… should we remove the old key to avoid getting this error?
Thank you.

From my experience, keeping the old key has no negative effect. The important thing for further updates is importing the new key.
On the other hand, I do not know whether the old key might be compromised now or in the future. In any case, it seems less safe than the new key, due to its inferior encryption.
And I don’t see any further use for the old key either. I will therefore probably delete it soon, if only to not mistake it for the new one again in the future and then possibly delete the wrong key.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.