On Saturday 07 January 2006 19:50, Ed Harrison wrote:

** Reply to message from "Mark A. Taff" on Sat, 07 Jan 2006 17:19:33 -0800

...

Try running this script I wrote to make sure all the keys are properly installed.

Fantastic idea. Thanks.

Ed Harrison, Registered Linux User #199533 SuSE 10.0, Kernel 2.6.15 PolarBar Mailer 1.26

You're welcome. For posterity, here is the mama script that actually installs apt4suse. This isn't needed to suse 10, as apt4suse is on the dvd. You will need to edit some paths, as I doubt /home/mark/Documents/src will work for you... #! /bin/bash # # `taffconfig.apt4suse` version 20050908 # Copyright (c) 2005 Mark A. Taff , GPL v2 # # This script downloads, installs, configures apt4suse # ###### # Source taffconfiglib functions TAFFCONFIGLIB=./taffconfiglib test -f $TAFFCONFIGLIB && . $TAFFCONFIGLIB # First, let's get latest version of install apt4suse rpm... if [ ! -d /home/mark/Documents/src ] then mkdir /home/mark/Documents/src fi cd /home/mark/Documents/src echo "*" echo "* Downloading..." echo "*" wget -N http://linux01.gwdg.de/~scorot/install-apt4suse.rpm sleep 2; # Install the install rpm... if [ -e /home/mark/Documents/src/install-apt4suse.rpm ] echo "*" echo "* Installing rpm..." echo "*" then rpm -Uvh /home/mark/Documents/src/install-apt4suse.rpm fi sleep 2; # Now run it to install apt... if [ -e /usr/bin/install-apt4suse -a -x /usr/bin/install-apt4suse ] echo "*" echo "* Installing apt4suse..." echo "*" then install-apt4suse fi # Update package list echo "*" echo "* Updating package lists..." echo "*" apt-get update sleep 2; # Fix pre-existing broken deps, if possible... echo "*" echo "* Fixing pre-existing broken dependencies..." echo "*" echo "* You may need to temporarily set key 'GPG::Check' to false " echo "* in /etc/apt/apt.conf.d/gpg-checker.conf until your system" echo "* is back in a consistent state." echo "*" apt-get -y --fix-broken install # Install/Update all rpm keys as required... echo "*" echo "* Preparing to install gpg rpm signing keys..." echo "*" count=0 numKeys=0 keys=`apt search rpmkey | awk -F " - " '{ print $1 }'` for key in $keys # `apt search rpmkey | awk -F " - " '{ print $1 }'` do numKeys=$((numKeys + 1)) done for key in $keys do count=$((count + 1)) echo "*" echo "* Preparing to install rpm key: $key ($count of $numKeys)" echo "*" apt --no-checksig --no-post install $key done

On Saturday 07 January 2006 22:18, Anders Johansson wrote:

So if someone ever cracks the apt repo, they don't need to gain access to the packager's keys, they can just add their own keys to the repo and calmly wait for everyone to install them

This isn't the right way to do it

Do you have a better idea, Anders? How else are we to get the packager's keys? Don't tell us it isn't right unless you are willing to tell us what _is_ right. Thanks. Mark

On Saturday 07 January 2006 22:33, Anders Johansson wrote:

I have, on several occasions.

There needs to be something like a web of trust. For example, we all get suse's key through the distribution, we trust suse and we can trust that the key is valid since the best hacker in the world can't alter a read-only CD/DVD.

So the solution is to have the packager's keys signed by suse if and only if they have established that they can be trusted. Then the users only import those keys which have been signed by a trusted source.

This can be delegated so that suse's key signs some delegate key with full trust, and this delegate can then sign packagers' keys. And of course suse's key doesn't have to be the only fully trusted key, so long as the others also come from fully trusted sources on fully trusted media

This has the drawback that not just anyone at any time can build a package and upload it to a repo, but it has the huge advantage that the repos can actually be trusted without having to trust the system admin

See, and this trust model is the exact reason that PGP public key encryption is rarely used in the real world. This model _just doesn't work_ in the real world. Probably works fine in a corporate setting where compulsion and force can be used to make people comply, or between a small group of people. But it doesn't work in the real world. I don't read the source code for every piece of code I install. And I don't read/write my own compiler, either. I trust the free market of free software. I trust suse to give me a basic system. I further trust certain third party packagers like packman. For each of these, I had to take the plunge and trust them initially, and they have since proven to be worthy of my trust. For the record, I really don't trust the centralized model you propose. I much prefer the decentralized market trust model. If nobody complains your packages are bad, I will operate with the working assumption that they are aren't bad. Yes, if a repository got cracked, it could cause some issues. But really, it is normal for there to be consequences when a system gets cracked. In this case, it is a minor issue. I simply remove the damaged repository from my sources list, and reinstall any potentially damaged applications. Your "solution" doesn't actually solve anything in the real world. A distributed reputation-based system _does_, and it has several millenia of history to prove the model works... Regards, Mark

On Sunday 08 January 2006 09:42, Anders Johansson wrote:

On Sunday 08 January 2006 07:53, Mark A. Taff wrote:

...

See, and this trust model is the exact reason that PGP public key encryption is rarely used in the real world. This model _just doesn't work_ in the real world.

Of course it works. It's just that people in general don't know or care about security. Your entire mail, for example, is more of an incantation than anything else: "Linux is secure, linux is secure". Well, it is, but not if people behave the way you suggest

...

I don't read the source code for every piece of code I install. And I don't read/write my own compiler, either. I trust the free market of free software.

I trust suse to give me a basic system. I further trust certain third party packagers like packman. For each of these, I had to take the plunge and trust them initially, and they have since proven to be worthy of my trust.

The problem is that without signatures, you have to trust much more than just the packagers. Trustworthy signatures would mean you only had to trust the packagers (and the developers of gpg), but without them you also have to trust the admins of the repositories and their mirrors, their honesty, their competence, their diligence, their backups for when they get sick etc. etc. etc. That's more trust than I can muster

...

For the record, I really don't trust the centralized model you propose. I much prefer the decentralized market trust model. If nobody complains your packages are bad, I will operate with the working assumption that they are aren't bad.

This is why so many windows users are happily running trojans, backdoors and zombies and don't know a thing about it

...

Yes, if a repository got cracked, it could cause some issues. But really, it is normal for there to be consequences when a system gets cracked. In this case, it is a minor issue. I simply remove the damaged repository from my sources list, and reinstall any potentially damaged applications.

heh, that's funny

...

Your "solution" doesn't actually solve anything in the real world. A distributed reputation-based system _does_, and it has several millenia of history to prove the model works...

Not really

No, the GPG model of trust is flawed because it doesn't accurately model trust in the real world. It depends on trust passing undiminished through n-degrees of separation, and no rational person thinks that way. I might trust SuSE, but I don't trust them to say that anyone else is OK. _I_ will make decisions on who to trust, not delegate that responsibility to some third, fourth, or nth party. I mean, come on, just because I trust a person to write a decent program without backdoors, etc, doesn't mean I trust their judgment of others' character and intentions! Linux _is_ more secure than Windows, and for now, it is secure enough. Perfect security isn't possible any more than perfect copy protection. What is important is to make the computer harder to compromise than the value of the compromised computer. As for your crack about windows users happily running trojans, etc, this is because they don't care if their machine is compromised, not because nobody has complained about a specific virus/spyware/trojan. If you refuse to heed the warning the market provides, it is your own fault. Yes, really. The reputation-based market model has been successfully handling this type of problem for millenia. Your centrally-planned model always fails outside of a controlled environment--See government licensing, see pontifications on science, see pedophiliac priests, appeal to authority, et al. Mark

On Sunday 08 January 2006 15:53, Anders Johansson wrote: <snip>

It's not a question of suse saying someone is trustworthy. It's a question of establishing identity. People who are forced to say who they are are far less likely to do silly things

It makes no difference whether you are talking about authentication, or trust, or the trustworthiness of the authentication--the fact remains that your chain of trust/authentication is only as strong as it's weakest link. Nobody in their right mind would trust an authentication scheme with more than 2 degrees of separation, at the _very_ most. <snip>

Except you don't. You have already said you will install packages from anyone at any time and if the packager refuses because the signature is bad you will find the gpg key on google so you can force the installation. You are a windows user in disguise

I never said I would install packages from anyone at anytime. Don't put words in my mouth, it's a sign of a weak argument when you resort to strawmen. Further, apt _never_ said the signature was bad, it said it not OK because it was unknown. Not the same thing. So when you decide that the unknown signature is indeed acceptable to you, you install it. The script I posted only installs keys for packagers who have packages in preselected repositories. Further, that script is only run one time when initially setting up apt4suse, so any malware must be in the cracked repository during that initial 30-second window. <snip>

The point I was trying to make was that if users of packages from a particular repo mirror don't know they are running malicious software, where will the warnings come from?

As opposed to malicious software from an iso? or from source-forge? The warnings will come from the same place they always do: from users who discovered the malware, either through careful scrutiny of their machine or by serendipity.

...

Yes, really. The reputation-based market model has been successfully handling this type of problem for millenia. Your centrally-planned model always fails outside of a controlled environment--See government licensing, see pontifications on science, see pedophiliac priests, appeal to authority, et al.

What on earth are you talking about. Pontifications (?) on science?? Pedophile priests??? Is this relevant to anything?

See http://www.m-w.com/cgi-bin/dictionary?book=Dictionary&va=pontifications for a definition. Those examples are failures of the same trust/authentication model you espouse, hence they are relevant.

The need to establish identity and origin is essential. How can you ever decide whom to trust if you can't even establish that the person you are being asked to trust is the originator of the package you are about to install?

And your solution is completely circular: I don't know if person x is who they say they are, so I'll ask y if x is who they say they are. But wait, how do I know y is who they say they are? I know, I'll ask z. z vouches for y, who vouches for x. Oh, but wait. y was actually a malicious user who deceived z. We get burned because we trusted z to accurately verify y's identity. Even though z was an honest broker, it turns out z is incompetent when it comes to authentication. At some point in your scheme, you have to implicitly trust a central authority, and at every node you have a risk of failure for some reason or another. Under your centralized scheme, if suse's key was cracked, then _every_ package/repository would be at risk. But if packman's key is cracked the problem is comparatively limited. The simple fact of the matter is there is absolutely _no way_ to be certain that software (or anything else for that matter) that you download is secure. Say suse signs packman's key, then packman makes packages and signs them. Great. How do we know packman's machine didn't get cracked, and the attacker then used packman's key to sign a trojaned application? Jeez, doesn't packman know that "God" isn't a secure password?* Or maybe the cracker swapped out a couple of *.h and *.cpp files, then left packman to legitimately compile, package, and sign the trojaned application? I'm sure packman doesn't read the source for every app he packages, each time he packages it. Does he read the source for his compiler, and then compile it? The bottom line is the security you yearn for isn't possible, and never will be. The best we can hope for is to trust certain sources to be honest brokers working in good faith, and then deal with the inevitable human error, and the inevitable malicious user. I'm done with this thread now, Anders (but of course I'll let you get the last rebuttal, if you like ;-). I think it is safe to say that we disagree about which is the better model. Regardless, this conversation certainly was entertaining. Regards, Mark * This is entirely ficticious, no offense intended to packman.

On Saturday 07 January 2006 20:10, Susemail wrote: <snip>

Thanks for the script Mark. Now all the keys are properly installed. But no joy yet.

Checking GPG signatures... Unknown signature /var/cache/apt/archives/libgpod_0.3.0-1.pm.1_i586.rpm: (SHA1) DSA sha1 md5 (GPG) NOT OK (MISSING KEYS: GPG#27db6f5b) E: Error(s) while checking package signatures: 0 unsigned package(s) 1 package(s) with unknown signatures 0 package(s) with illegal/corrupted signatures E: Handler silently failed

Any other ideas? Is there some way to change the signature to the correct one?

No, not that I'm aware of. If you google for GPG#27db6f5b you should be able to find the correct key and install it manually. I did this once, but don't recall exactly how. I know I downloaded the actual key file, but then the memory gets foggy... Instead, you could try removing the apt-repository that has this problematic file from your sources list. You could also try specifying an earlier version of the problem software. Something like: `apt-get -V install libgpod=0.2.9` You will have to use `apt-cache showpkg libgpod` to find out exactly what versions are available. And at long last, you could try waiting a few days. I've had issues with apt repositories before that were fixed in a few days after the error was noticed. And continue to run apt-get update to make sure apt is aware of the latest packages and signature files. HTH Mark

On Saturday 07 January 2006 20:10, Susemail wrote:

Any other ideas? Is there some way to change the signature to the correct one?

Now that I think about it I seem to recall one time when rpm didn't recognize the new keys until after I rebooted. I know that there is a command to fix that without rebooting, but I didn't (and don't) know it. It may not be a bad idea to try rebooting, if you can afford the system downtime. I'm sure someone here knows the proper incantations... HTH Mark