Numerous Debian Project systems compromised

Posted Nov 22, 2003 4:28 UTC (Sat) by IkeTo (subscriber, #2122) [Link]

- It has become time to have packages which you can install without having root privileges while running the install and deinstall scripts. Only a select number of packages would need them anyway. The only thing you need root priviliges for in a 'normal' package is for extracting your files, which is something which is checkable and containable.

You have no idea of what a package actually does. Most packages must be installed as root. E.g., libraries must install to one of the standard places or they won't be used at all and programs using them will vomit with a message saying library not found. Many packages needs to be able to write to /etc and /usr/share so that they can install the configuration files and data files. Many needs to run daemon processes. If an individual user needs to install something, he can get the package, unpack it himself, put the binary into somewhere he wants, and hope it work. But most likely, it won't. It is more likely than not that at the end one needs a re-compile to change the locations where configuration and data files are to be found. Of course, binary packages are meant to be compiled, and so it means that it is not something that is supposed to be done by the package anyway.

- A network of 'package checkers' should exist, which compile Debian packages on their own and compare the compiled version with compiled versions on the servers. This should be distributed, so everyone who wanted to donate some CPU cycles and bandwith would be able to do so. Some kind of background task like SETI@home which would check a random package per day per computer or so. This would not help against source-code comprises, but it helps against trojaned binaries without knowing how it was trojaned.

Did you even try to compile two programs in two individually configured computers and compare them? If you did so, you should know that they won't be the same: anything from compiler version to compiler configuration to library version to date of compile will make the actual binary file different. Trojaned binaries can already be checked by using the MD5 checksum now. Your approach would actually help, in the case that the compilation process in the Debian Developer is compromised so that sane source file produces binary files with a trajon horse. But then, if the Debian developer's computer is compromised, I think nothing can be guaranteed anyway.