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: OpenOffice.org:STABLE OBS Project <OpenOffice.org:STABLE@build.opensuse.org>
Schlüsselfingerabdruck: D3948FAFB8FD4AB39FBBB90694F9ACD253809572
Repository: openSUSE BuildService - OpenOffice.org
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.
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
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.
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>).
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.
I imported and signed that key now, and uploaded it on the keyserver.
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.
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.
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.
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.
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 Apache.org compromised [LWN.net]
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
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?
