On Oct 28, 2004, Matias F�ciano <feliciano.matias@xxxxxxx> wrote: > As often as the server is insecure. > Do you mean the build server is a total disaster about security ? It means lots of people have build access to it. If having build-user access to it implies being able to attach a signature to the package, it means anyone with build access is able to obtain the signing key. > If it's the case, why should I even trust unsigned rpm ? Oh, so we're getting somewhere here. Maybe you shouldn't? > Just curious, How many time the build system have been cracked ? None that I'm aware of. And this wouldn't have affected the key anyway, because they key is not part of the build system. But in order to have automated signatures stapled to packages, it would have to be, and the key could easily leak. > All you say is "if ..., if ..., if ...". > Should I continue to flame with other "if ..." ? If you like :-) But if we decide to do so, what if both of us become closely familiar with good security principles? You see, it's about analyzing risks and determining how to minimize risks without excessive costs. Without considering theoretical scenarios (to avoid the word), it's very hard to do any such analysis. > With unsigned rpm, no "if ..." is needed. I can definitely not trust rpm > package. Period. Exactly! But with a signed rpm, you get a false sense of security because you may think you can trust it. But you can only trust it, to whatever extent you choose to trust it, if the key is known to be safely guarded. If it isn't, you're just fooling yourself. The signature is actually working against you. >> > What append if the build server is cracked ? >> > Nothing. It's like having none signed rpm (like the current practise). >> Not quite. People would still trust the old key > Come on... > Right now people are "forced" to _always_ trust unsigned package. Err... Come again? Who's forcing anyone to trust unsigned packages? I haven't signed this message. Am I forcing anyone to read it? I don't think so. If you read it or not, and if you choose to believe I wrote it or not, is up to you. I'm not forcing you anything. I'm not even compelling you to write a reply (quite the contrary ;-), but you will anyway :-) > The current situation is worse than "one day, some people wrongly > trust a key". You got a very twisted view of good/bad IMHO. > Do you think it's a good security practise ? Certainly not. Personally, I'd much rather have all packages in rawhide signed. But with a properly-created signature. Failing that, I'd write a script to repeatedly attempt to update, progressively adding exclude arguments to up2date or yum, until it installs a complete set of signed packages, and wait to get the unsigned packages in the next rawhide push. Failing that, I'd be more than willing to live with a signed-rawhide repository, that we could build the way I described in a previous posting. Failing that, well... Maybe we could create a community of volunteers who would keep monitoring the mirror sites looking for corrupted packages, and maybe even offering rawhide mirror-like sites with additional signatures attached to the packages. >> until they find out > A new argument. The "if ... until ...". /me is happy you're finding patterns in my arguments. Now maybe you could focus on the content instead of the form :-) >> about the revocation and, by then, it might be too late. > With unsigned rpm, if any single mirror is corrupted it's already too > late to do whatever. If any single mirror is corrupted, it's too late for people who got a package from there and didn't check it before installing. Yes, checking is a pain. > Sorry for this "if" argument. Don't be. It's a perfectly legitimate way to consider dangerous situations and assess their risk. >> Not to >> mention again the need for obtaining new keys whenever this happens. >> > gpg --gen-key > gpg --export --armor key > PUBKEY > ftp ... "put PUBKEY". > Anyway. we will be back temporally to unsigned rpm. No more. You're missing the point. Why would I trust a random key I obtained from an ftp site? Such a key would have to be signed by another Red Hat key to be of any value. No big deal for those who understand the issue, but how many people you think would check the signature in the key, to verify that it's legitimate? How many people would fall for a fake e-mail from Sopwith announcing the new Fedora Rawhide automated-build signing key, with instructions on how to install it such that up2date will use it. Instructions that could also get up2date or yum to use a mirror known to have been broken into. >> > What damage this will cause the Red Hat business ? >> >> Having keys revoked and new ones issued would definitely look bad. > I have a revocation certificate for my key. Should I stop using gpg > because *perhaps* I will need to use it ? Certainly not. But if you don't protect your key and actually need to revoke it, it shows that your security practices could use some improvement, and people would decrease the amount of trust on your key (not to mention your stock) > This doesn't make any sense. It does to me. > Suppose my mirror (or http://mirrors.kernel.org/) is cracked then > Slashdot will be happy to point that Red Hat don't sign their package > even if the build system is not cracked. > The reputation of Red Hat rely on _all_ mirrors if packages are not > signed. And if it becomes so difficult to explain to people at Slashdot why it is so as it is to explain to you, that appears to be way more competent in the subject than the average Slashdot reader, we're bound to lose no matter what. > If the build system is cracked and Red Hat don't use signed rpm do you > think it's better for the reputation of Red Hat ? Definitely not. Getting the build system broken into would be a terrible thing. Getting a random mirror site broken into is, well, a problem, but it's not Red Hat's fault. Getting people to trust such mirror site isn't Red Hat's fault either, but it's something Red Hat could help avoid by signing all packages, yes. Unfortunately such signing is not practical, and gets in the way of the real goal of rawhide (which, as you know by now, is to get a backdoor into everybody's machines: any Red Hat developer can build a package that makes to rawhide and, next day, he'll have an army of zombies ready to launch his DoS attack against www.mycrosoft.com. Too bad there's a typo in the site name ;-) Yeah, getting fast turn-around for people to test packages is a secondary point. ;-) >> The trick here is: how to get the signatures automated without >> further exposing the key? > Do what you can. I thought we were already doing it. > If the key is cracked in 2 mouths I'll enjoy using signed package during > 2 mouths. Still better than nothing. And next day you'll get a malicious package installed on your box and you'll be left with, well, nothing. Ok, that's not worse than nothing, but it's worse than *your* nothing above :-) > Here is the point. Currently Red Hat does not *want* to do any thing for > the security. Red Hat is doing what it can, and pretty well. Doing what you want would open a huge hole in the system, and would cause a lot of damage, although you can't see that. I've already exposed my arguments, and I intend to step out of this debate now. I've already spent far too long exposing good security practices to someone who doesn't seem to want to listen. I hope at least others have benefited from the discussion. > It is the decision of Red Hat (btw, Slashdot will be happy to know > this). All these "pseudo technical" arguments are not relevant. Oh, wow! pseudo technical arguments. I didn't even know I could make those. Cool! I'm *so* happy. Just to make it clear, I don't speak for Red Hat, and I'm totally unfamiliar with the procedure Red Hat uses to sign packages. I'm just working on assumptions driven from some knowledge on good security practices, and a bit of common sense. I thought it would be important to make this clear, before it hits Slashdot. Not that the average Slashdot reader would pay attention to this fine point :-) Thanks for your attention, -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}