Checking signatures for installation sources

The tool “zypper 1.14.4-1.1” shows messages like “File ‘repomd.xml’ from repository ‘…’ is signed with an unknown key ‘’. Continue? …” for a while. Now I wonder about the status of further software update possibilities from these installation sources.


  • filesystems
  • Printing
  • server:/database

I have not been seeing that. However, I’m only using the standard repos (plus packman).

You can try removing a repo, and then adding it back. It should then prompt for approval of the signing key for that repo.

There was a recent update/change to some signing keys, though I’m not sure which keys were affected.

NOTE: one way of removing a repo is to rename the repo definition file (or move it to a different directory). The repo definition files are in “/etc/zypp/repos.d” and have file names that end in “.repo”. If you remove a repo this way, you can just as easily restore it.

I am using an extended selection of available installation sources.

You can try removing a repo, and then adding it back.

I would prefer to trigger the refresh for proper management of involved keys by a direct command (instead of such an action).

There was a recent update/change to some signing keys, though I’m not sure which keys were affected.

I noticed a few corresponding updates for these keys.

There is an “rpmkeys” command for adding (importing) a key. But you first have to find the key.

How should the appropriate keys be determined for mentioned repository examples?

I don’t see this. I too have the filesystems repo active, but not even on that one. Does

zypper clean && zypper ref 

change anything?

Also, show

zypper lr -d

Not for the desired handling of installation keys on my system.

zypper lr -d

The additional repositories from my openSUSE build service selection have got different priorities so that the recommended variants should be picked up by default.

Is that an explanation why you did not show the

zypper lr-d

as asked?

I hope so. - I would like to avoid the distraction because of a special repository selection.

Which software component is responsible for the information “… is signed with an unknown key ‘’. …”?

A proven method to get a mix of distro and non-distro packages, i.e. an unstable system, and saying absolutely nothing about vendor change of packages. As long as we don’t know abiut your repos, I have no option than to guess the blame for the issue lies in described mix of packages.

A more general remark then.
When people here spend some of their spare time to try to help you and think they need more information from you, you are of course free to refuse for whatever reason. But do not be surprised then when people leave your thread and go for some more rewarding action, like get a beer, go walking or try to help in another thread.

For many people coming here with a problem means they weren’t able to solve it themselves. The reason for that may be many fold. Apart from a direct answer from somebody with outstanding knowledge about the matter, there are other ways that problems may get nearer to a solution. E.g. looking to the problem from a complete different side (one that never came to a OP’s mind) might shed a lot of light and lead to solution. This approach means that people ask for info that the OP never thought about as being important. Refusing to provide it because OP insists on finding it of no use will cut off this approach completely. And alienate the OP from those potential helpers. Also for the future.

  • Do you occasionally dare to mix the available repositories for special requirements?
  • Would you eventually become interested in a clarification for the currently installed/active software dependencies?

I imagine that a corresponding software behaviour clarification can also work without the repetition of another repository mixture. Are concrete dependencies between involved software components more relevant?

OP no give requested information.

Me no give solution.


Having the same issue, even with just one repository (tumbleweed-oss) in repos.d:

**surface:~ #** cd /etc/zypp/repos.d 
**surface:/etc/zypp/repos.d #** ls 
**surface:/etc/zypp/repos.d #** cat tumbleweed_oss.repo  
name=Tumbleweed oss 
**surface:/etc/zypp/repos.d #** rm -rf /var/cache/zypp/* 
**surface:/etc/zypp/repos.d #** zypper ref 
Retrieving repository 'Tumbleweed oss' metadata -----------------------------------------------------------------------------------------------------------\] 
Warning: File 'repomd.xml' from repository 'Tumbleweed oss' is signed with an unknown key ''. 

    Note: Signing data enables the recipient to verify that no modifications occurred after the data 
    were signed. Accepting data with no, wrong or unknown signature can lead to a corrupted system 
    and in extreme cases even to a system compromise. 

    Note: File 'repomd.xml' is the repositories master index file. It ensures the integrity of the 
    whole repo. 

    Warning: We can't verify that no one meddled with this file, so it might not be trustworthy 
    anymore! You should not continue unless you know it's safe. 

**File 'repomd.xml' from repository 'Tumbleweed oss' is signed with an unknown key ''. Continue? [yes/no] (no): **

Any ideas how I can fix it?

Based on the information I would guess you manually added the repo and did not include the option to import the key…

Remove and re-add via;

zypper ar -f -g -n "Tumbleweed oss" tumbleweed_oss

Not sure why you want it to be a lower priority from the default 99, that can create issues.

Same issue after removing and adding the repo using the command from above.

95 is a higher priority than 99, btw :slight_smile:

Yes, but the way zypper works these days by switching won’t let that happen properly from other repos, just a zypper dup is all that’s needed.

So what is the output from;

rpm -qa |grep pubkey