how to verify a repository key?

I’ve just run “zypper se ekiga”, and upon refreshing the repos, it said there’s a new key for the OpenOffice Repo:

Neuen Signierungsschlüssel für Repository oder Paket erhalten:
Schlüssel-ID: 94F9ACD253809572
Schlüsselname: OBS Project <>
Schlüsselfingerabdruck: D3948FAFB8FD4AB39FBBB90694F9ACD253809572
Repository: openSUSE BuildService -

and then it asks if I want to trust this. Nice - but how to verify I want to trust it? Where is the web site that has the key fingerprint to compare? Shouldn’t that be a lot easier to verify? Or does noone care anyway? Then just don’t display this question.

mfg zmi

If I were you, I wouldn’t worry too much about trusting… Just trust it. It’s unlikely something bad will happen.:slight_smile:

Not to worry about trusting means not to worry about security. It is several days already and there is no information on the new key - just several complaints of the users :frowning:

I always find these bizarre has any one created a web of trust then and you trust these keys.

Tell me how did you all confirm the keys for the install? Just so I know and can do it myself.

The key is self signed and countersigned by the build service, do you trust it well did you trust the first one. So next we check registered keys lets see how many other keys we can find.

gpg2 --search-keys --keyserver hkp://

So all this BS without a web of trust is exactly that BS, Building your web of trust you trust the distro keys without a web of trust but suddenly it counts when a build service repo changes it’s keys…

Pearls for swine I fear, most “users” can only whine but don’t get active on the issue.

A few years ago, after one of the typical “whinig avalanches” me and two other users started telling (l)users to sign the keys they trust and submit their signatures to public key servers to increase the trust of those signing keys and it was a few happy days, when some people really did.

Somebody has to start the chain and trust the key, especially when there is no person directly associated to a key (even with personal OBS repos, packages are signed automatically by the OBS, the signing key is not a personal key of the packager).

A few weeks later, the same thing happened again, with a significant amount of the same people complaining again although they knew what to do to make the keys more trustworthy.

So I gave up, let the people complain, public key encryption/signing is destined to fail on behalf of people who forget about the base of real security, active trust.

The only way on never having to trust OBS keys is not to install any packages from OBS and only use the official repos OSS/NON-OSS/Updates, which leaves you to trusting the keys of those three repos, which are distributed on the installation media (which is then the only thing you have to trust, meaning that nobody gave you a faked ISO or <insert theorie of conspiracy here>).

Have the install media, it’s there.

What’s up with all of you? I asked a simple question, and the only replies received are “just don’t care” or “what, you don’t know you need to ASDFASDHn and then asdfDSAF and simply ASDFjheH”. No wonder this pisses off any users.

Stop flaming.

  1. I imported and signed that key now, and uploaded it on the keyserver.
  2. If you want more users do that, make a simple HOWTO web page explaining that step by step. Don’t blame users for not knowing it, instruct them.
  3. put that key into the repo, or on a web page so users can doublecheck it

While I trust the OBS, it puzzles me when a key is changed. Why has that been done at first?

Then, zypper asks me if I want to trust that key. Nice. So I wanted to check if really the key changed, or a hacker managed to DNS spoof or whatever. Simply that. The infrastructure is there, it just has to be filled with easy instructions and the possibility to doublecheck a changed key.

mfg zmi

Hmm, this has been an interesting discussion. I’ve always just trusted the very few OBS keys presented, never had a problem so far, and not gone into it that much, so thanks for the analysis.

Akoellh, glad to see you are still with us.

Maybe because all keys have a “limited” life time (on purpose), consequently expire one day and then have to be renewed?

Even Packman’s key has been known to expire in the past, accompanied by much gnashing in the fora. You trust that one without installation media don’t you (?).

So tell me where was I flaming I was educating you to the fact you’re relying on false security… Without out a web of trust…

I point you to the documentation so you can read it your self…

Either you trust the source of the key(Signed pkgs) or you don’t? Without a web of trust it is as pointless as you signing it I don’t know you from Adam.

So as you can’t follow links(Note flaming)

Key validation is more difficult. If you do not personally know the person whose key you want to sign, then it is not possible to sign the key yourself. You must rely on the signatures of others and hope to find a chain of signatures leading from the key in question back to your own. To have any chance of finding a chain, you must take the intitive and get your key signed by others outside of your intitial web of trust

I even showed you how to search for the key or any other keys masquerading as it…

There is no web presence to an OBS build repo. If you’re lucky they may have a mailing list if it concerns you get in contact with the repo maintainer/project leader and ask them to create a web presence but seems a little demanding to me.

As Akoellh pointed out conspiracy theory…

You’ve still not told me how did you check the key the first time around?

Remember its not me thats worried its you so I want to know how I can replicate what you did when you added the repo first time around.

Don’t rembember. Maybe had stress and just answered yes. But that aint the point.

The question is: What should I have done?

On most download sites you have a link to a .tar.bz2 and a link to the .md5 or .sha checksum. You can verify easily. One should do that, read about the hacked Apache downloads at compromised []

Here, we use zypper/yast for everything, which is very convenient. Why can’t there be a simple file containing the key signature in the download rootdir? Index of /repositories/ could containt a simple “actual.key” file containing the key, and/or “key.sig” with the signature. Or maybe on or Additional YaST Package Repositories - openSUSE

So instead of blaming me, try to just listen to the problem, and find a simple solution. I’m not whining about key, just of the inability to simply download/check the key somewhere. You as hackers working on a project know everything about it, but normal users don’t want to spend a day to search for “how do I do that secure”. Either I find it immediately, or I skip it.

And if you want users to trust+sign your keys, write a howto and urge everybody to follow it. Link it from the “key.sig” file so people can find it :wink:

mfg zmi

Mmm you download the key from the repo…

Index of /repositories/

And if you don’t trust the repo then why add it?

It is exactly the point you didn’t worry then but worry now! You clearly have little understanding how it all works which is why I pointed you to the documentation. if you worried at the beginning then you wouldn’t of added it and would of stuck to the keys with the iso…

If you wish to feel safe and secure because you downloaded some key from some site who am I to contradict you. Me I know this guarantees nothing and even on some site doesn’t guarantee anything, you add unofficial repos then grumble they have no web presence.

Not my key…

Its your paranoia you work out how to deal with it, me i’ll trust the build service repos just as much as I did before hand… To make keys beneficial isn’t just as simple as downloading and checking as I pointed out you could sign it I know you from Adam, perhaps you’re collaborating with insert malicious user.

There isn’t a simple solution to a complex problem it involves getting the guys and gals hosting counter signing each others keys(But this can only be done face to face for proper security (insert conspiracy) then hopefully there will be someone in the chain that you trust…

The conspiracy you fear is that some one who shouldn’t have access to the repo has uploaded a pkg well without a web of trust that could still happen.

zmi raises a very good point. If we are going to trust repository keys without verification (the first time we install, when we add repositories, when the keys expire) then they are essentially useless for security.

For the sake of argument, how could I confirm the keys?

When I visit an SSL secured site, I can verify their certificate because it has been signed by Verisign or some other CA. Why do I trust Verisign? I don’t, necessarily, but it’s an easy matter to check the root certificates “verifying” Verisign that are installed on my workstation against those installed on lots of other workstations.

Is there a similar mechanism to verify package repository keys against some authority with a reasonable degree of confidence?

On Sat, 13 Mar 2010 07:56:01 +0000, novelgazer wrote:

> Is there a similar mechanism to verify package repository keys against
> some authority with a reasonable degree of confidence?

I found this thread on the OBS mailing list from earlier this year:


Jim Henderson
openSUSE Forums Administrator