On Wed, Dec 05, 2007 at 08:46:16AM -0800, new_guy wrote: > Can you dismiss PKI
Seems they do. The problem of signing code does not remove the problem of checking the signature. When you sign code and when you ask developers to do so, they need to own some private key which will let you check on the other side with a public key. This private key will have to be very protected. Now, what happens if there's a problem and that key is lost or stolen ? And more specifically, what will happen if this very trouble happens and no ones does see it ? The key can be stolen without anyone knowing and then ? Of course, a blatant and direct hack will be detected but someone who does steal a private key is very cautious in acting as if the key is still secure (exactly like the Allies were able to decipher Enigma encoded messages because of re-use of IV-alike blocks by german submarine crypto responsables or predictible IV-alike according to the date on calendar : the Allies could read a lot but did not act on most and let some ships go down because they needed that secret, being able to decipher, to be kept a secret in order to remain a strategical advantage). You have two main things here. The code signing can be used in the developing process to only let developers add code (this would be another layer over the authentication that already does exist when they do cvs commits to the OpenBSD source tree) and that's Theo (and his developers) choice. If the technology is available and if those clever guys dont use it, I think there's a *hint* there. History has proven Theo and his folks do know a lot about security and especially its culture. Then, you have the distribution itself. Having the hashes stored at the same place as the files itself is not the best thing because if someone is able to change a file on a FTP (be it an official or non official ftp repository) I would hope this cracker will be clever enough to also update the hash files. Having the hashes being signed in some way could help if they are stored at the same place as binary or sources files, and if it's a writable media. Ok. Why not. But how many people are really going to download sources and/or binaries and have a gnupg locally installed PLUS having the public key that goes with the signing private key and are going to check ? Very, very few. If you want this to work, it has to be automated. Otherwise, it's going to be a lot of work, a lot of time spent by people that are quite busy and not for a lot of people on the other side that will really use it. And here comes the head of the nightmare snake we all know about : implementation. Security is a good thing to have. Ideas that can improve it too. But implementation is critical, as it's very often a weak point to attack (remember Netscape's PRNG generator used to attack its SSL ?) And if I remember correctly, Theo often said that if you do think a feature is missing, you should code and shut up and when it's working, tell the people about "hey guys I did start from OpenBSD and did this and that to improve the distribution security, how about using it now since it works and it's a real friendly license ?" I do not think thus that adding signing to sources will help that much and if it does, the openbsd devs will do it if it's really a good thing (openbsd, openssh.. those guys fucking now what they are doing man..) Signing the hashes could help but you do know very few people are really going to check those. And when you do binary installation, you have hashes of the packages (source and binary) that are used and automatically checked when using ports. This is good because it is systematic and automated. But the problem of trust remains : a signature proves nothing. It just tells you that a package is indeed signed by someone you probably dont personally know and you should ask yourself if you trust him/her. And if it comes to a trust problem, well don't use it. History did prove them right and serious and that's enough for me. And I trust my backups first or before anything else. -- unzip ; strip ; touch ; grep ; find ; finger ; mount ; fsck ; more ; yes ; fsck ; umount ; sleep
