...making Linux just a little more fun!

The Answer Gang

Contents:

¶: Greetings From Heather Stern

linux server for xwindow....need hints

hard links

entering into the interactive mode

SuSE 8.2 Linux Distribution and Soundblaster 16

Kernel Compiling and Framebuffer Device

Question about Laplinking

Greetings from Heather Stern

Howdy folks, and welcome once more to the world of the Answer Gang. In fact, welcome to the dusty virtual garage of your erstwhile Editor Gal. I've got the Weekend Mechanic in here passing me a spare wrench and hanging out, splitting some ginger beer with me.

Number of threads that came through was a bit low, I guess the summer months have people running about and enjoying life instead of hanging out by their computers quite so much. Dumb questions of the month seem to be at an all-time low ...

So, this time around, the Answer Guy himself, Jim Dennis, asks:

How do you know you can trust these packages?

GPG itself is both a cool thing, and an embarrassment. It's fairly well available nowadays - free flavors of it for everybody - and some nice helpful GUIs try to integrate it into day to day life. But there's a problem - it's not easy enough... and that's built into the way it has to work. It's an embarrasment because it's just hard enough to really use day to day, that people who probably ought to - don't.

Mind you most people just don't have the patience to get a few solid spokes in their web of trust. Mostly they just establish a few crosslines here and there to people who knwo them so well they'd trust their identity directly anyway.

So how do we really know kernel.org's key is ... well, itself? If the webserver got mucked with, how do you know this wasn't a target? For some random distribution, how do we know our install discs are safe?

Well, we buy them, and they're on a pressed CD, so we know they came from that vendor, so...

Nice try. A lot of people get a free or cheap disc from a less perfect source. And it certainly hasn;t happened to any Linux vendor yet, but in the mswin world an occasional software vendor has mistakenly shipped a trojan or a virus. Being a commercial pressing is good, but isn't really a guarantee.

Commercial distros restrict who can commit to the product release, and that can be considered a good thing. Debian's build servers use GPG to very the identity behind a package sent to them. But what we, the sysadmins and other users, can't be really sure of which build server a given rpm or eb or tarball really came from. Some of the systems allow checking that the download server you have reached is authentic. But if it got sent junk - ouch. I think it even happened to one of the distros once, though they spotted it in very short order.

Build computers should automagically sign packages, the way mail passing through a system gets marked up with a Received: header. In fact the analogy is pretty good - right down to dirty liars forging a few fake ones behind themselves when they want to send junk. But then folks like you and I have to be able to establish that the keys are good. And that process takes human energy.

Why? Because we can't just have the computers randomly make up keys. A person's got to create a key, sign itself, get a few of his buddies to sign the key, really use it. As a web of trust grows, a key identity is well known, and you could say you recognize a given key as good the way many people can recognize a particular actress or other public figure. You gotta hand it to the debian guys for keying with each other so they can be sure of who's sending what... but that's for sending them up to their core servers. The build servers work automatically to crank out official .deb files, but WE can't tell where they were built. Even if the build server did sign these packages (good idea) then how do you and I know the key is trustable. Let's get serious, it's pretty hard to get a silicon lifeform to come to dinner and show you its state ID or some of the other things people do to prove they're themselves. Ok, so the sysadmins sign the key. But you can't just have the key with no passphrase - if you did that, anyone who somehow got to it could steal it, then use it to build wicked packages all they liked. No way. So you end up with a critical system which has to have someone take a look at it and load up the key again if it has to reboot.

Maybe if we have more than a few sysadmins know the fingerprints of these keys that should be so well known, it'd become reasonable to have checkable signed packages. In fact let's go one further, the rules or spec or whatever it is inside a package that makes it something more than a tarball, should be signed by the coder responsible for the package. And if they don't check out we don't care which totally trustable build server built this toy. And let's get these important keys' fingerprints into some places that can't be cracked and spoofed. Get these things into printed manuals, into magazines (maybe just a few at a time, random good ones that the staff have managed to verify), and onto pressed CD covers where applicable.

Okay. Say you've all your ducks in a row and all sorts of things are signed... and verifiable. Everybody knows who everybody is. Then we narrow the field of problems down to the merely ordinary - once you know who's who, then you can really ask yourself if they know what's what or are doing what's right.

But at least you know who you're talking to and who you're getting your bits from.