On Wed, 16 Jul 2003, David B Harris wrote: > Hardly. Every Debian Developer has the ability to run arbitrary code as > root on everybody's system. Do you want to try and make the argument > that regardless of whether the person has proved spiteful, unstable, > mean, and just generally a jackass ... right, are you wanting to make > the case that even if they've proven themselves to be totally unreliable > and untrustworthy, they should be allowed to run code as root on > people's systems because they're technically capable of writing said > code?
I personally don't find this argument compelling. Like it or not, the open source community is one built on trust, together with the fact that having access to source and many willing and capable testers, problems are detected and flushed out very quickly. But read on, I believe that the trust issue can be overcome. > Indeed, pretty much every stage except for the DAM stage checks for > technical details. Do they understand the DFSG? Do they know how to make > a package? Can they prove they are who they say they are? > > At this point, as far as I know, only the DAM stage of the NM process is > where the individual is looked at as a whole. And the only argument here is that it's a huge task, and the DAM doesn't seem to be able to keep up with applicants. > Getting rid of that examination would be very detrimental to Debian as a > whole, and will likely result in some very, very unpleasant things > happening to the Debian community and to our users at some point. Once again, I don't anticipate an apocalypse, but it is conceivable that some unpleasantries could arise. I can think of a couple of things that would make the system a bit more fool-proof: 1) Not everyone should be able to upload every package. Unless you are the established package maintainer, or until you file an ITP, and that ITP is accepted and approved by some yet-to-be-delegated body in Debian, the installer will simply throw away your package. This eliminates the danger of an NMU/hijack of binutils that rootkits everyone running unstable. It can also help prevent more subtle mistakes and attacks that could land Debian in much worse trouble than a trojan horse. The wrong piece of non-DFSG code uploaded into the archive and then distributed via our archive and mirrors system could wreck the project entirely. Having a checkpoint before stuff gets into our distribution mechanism seems prudent anyway. QA and security folks should be able to NMU/hijack at will. They are delegates, and are therefore entrusted with the extra authority. There may be other delegates who should have this authority as well, but it should be controlled. 2) Since the DAM can't look at *everyone* in explicit detail, I propose that we extend the concept of advocacy beyond the NM phase and on into maintainership. If I were to advocate a script kiddie who actually tried something malicious, then it should my ass, my key deleted from the keyring, as well as the kiddie's. I think there are other advantages to this as well, such as encouraging a certain sense of community, maybe even teamwork. Also, the "strong advocate" method doesn't have to be the case for every applicant - the DAM could continue with the process as today for folks who couldn't find, or didn't want to tied to an advocate. 3) A mechanism to revoke maintainership probably is necessary. After all, if you decide that you can't contribute to the project for a while, why should Debian run the risk of keeping your account open. You should at least orphan all of your packages (hence "unregistering" your ability to upload them) and have your machine accounts disabled. When you're ready to come back, given that you were worth a damn the last go around, it should be no problem to get a DD to advocate you, and then you're back in, contributing to the cause. Beyond that, a delegate group of the DPL that could exterminate the accounts of unsavories seems like a necessary evil. I'm not sure that we don't already have that today anyway. 4) I'm not sure why everyone needs machine accounts. Or for that matter, even a d.o email address. Sponsored maintainers seem to be able to get along pretty well without either of these. (At the same time, I don't see why the email address should matter either way.) Anyway, this thread should probably be on newmaint, so I'm cross-posting it there. Please follow-up on newmaint. Cheers, tony [EMAIL PROTECTED] | An ounce of perception, http://www.debian.org | a pound of obscure... | (Peart)
