Numerous Debian Project systems compromised

- 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.

Is it something that can prevented by better hardening of the servers?
Was it due to unapplied patches or misconfiguration? Bad passwords?
GPG bugs? Compromized systems which were trusted by the server?

I also wonder if there is any connection with the recent modification of
the Linux CVS gateway.

I think we can better protect ourselves in the future if we understand
how these attacks are being perpetrated.

It doesn't hurt the cause if people around the world, especially those who don't know the technical ins and outs of computers, could understand the nature of this beast in our field.

People who advocate more liberal drug laws are familiar with it since day one. There was a time, in the 1970's, when it actually became quite fashionable to spurn informants and people who betrayed one's trust. In our industry, however, we are currently at a point where we are still quite able to identify, and *expose*, people who are willing to sell out to the likes of Microsoft and SCO by engaging in clearly criminal behavior.

It was said earlier that bringing in law-enforcement could mean that the servers would be impounded, but there must be some better way to do it. People who violate the law by breaking into the property of others should be punished, and that's that.