On Wed, 16 Jul 2003 21:33:11 -0700 (PDT) tony mancill <tony@mancill.com> 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. Hahaha :) The FOSS (Free/Open Source Software) community is *not* built on trust! Quite the opposite. We, as users of software, do not trust the developers to write bug-free code. We demand the ability to fix it if required. We do not trust the authors to write trojan-free code. We demand the ability to examine it. We do not trust the authors to add each and every last feature we want (and they shouldn't!), we demand the RIGHT to do so ourselves. Have you tried randomly getting RCS commit access to a random project lately? Go ahead and pick one, something that is *never* run by a privileged user (say, bonnie++). Let me know if you can get it without proving your trustworthyness beforehand. When you're done that, go ahead and actually pick something hard - say, OpenSSH. Once you've accomplished all that simply because they "trust" you, without doing any checking, you can go ahead and tell me that the community is built on or based on any kind of trust :) Debian's community, certainly, isn't based on trust. And it damned well better not be. At least 90% of the people I know would immediately stop downloading packages from Debian if we allowed just anybody to upload code to the archive. (I will respond to your later comments ... later - I have read them :) They'll also start migrating towards another solution. I, and many people I know, routinely audit packages just for the hell of it, to make sure everything is on the up-and-up. You'd be surprised at some of the things that have been found. Nothing malicious that I'm aware of, but some pretty braindead things nevertheless. > > 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. That assumes that everybody who's been on the queue so long hasn't been examined. How do you know that they *weren't* examined and found wanting? I know of a halfdozen cases where real trolls applied, and if the DAM had given any response, there would have been no end of trouble. As it stands, those six cases (and these are just the ones I'm aware of) have simply been forgotten by the troll in question. Few trolls are willing to bother waiting around, whereas people who honestly care can do *heaps* of contributing while they're waiting for DAM approval. I know of two cases where the applicant in question was just a plain old dick, and unstable to boot. They were also put on hold and are to this day. If they really cared, they could contribute huge amounts to Debian, in all levels. I have. And it's been pretty easy, too. > > 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. This would certainly stop a malcontent from putting a trojan in a very popular package that's run as root (I like the OpenSSH example), but in reality that's already the case. NMUs are noticed quite quickly, and anything suspicious (especially for a package like that) will get pulled out of the queue until the situation can be clarified. Unfortunately, it will force the Debian user base to filter which packages they install based in maintainer. The long, detailed application process with the personal examination by somebody who is held responsible for his or her decisions lets us get away with not providing facilities with this - the chances of anybody including a trojan in a package is pretty slim at the moment. However, take that process away (or take away the most important part - making sure the applicant isn't certifiable) and the users will have no recourse. They wouldn't be able to trust the application process without that step. Frankly, if I'm right (and I do think I am - at least a number of Debian users [non-developers] *say* that's correct), then I figure people will just stop trusting Debian as a whole altogether. Nobody outside of the Debian development community knows enough maintainers well enough to judge their trustworthyness to install even base+standard. It's either Debian evaluating these things, or nobody. That also doesn't even get into the problems such a system would have. NMUs have been very productive, and not everybody who does them is part of QA or similar. > 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. See above about this. At the very least, talk to the DAM or those who help him. Maybe ask the DPL. Ask the people who actually know what's going on. > 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. If a maintainer is found abusing his or her access privileges, you can be sure they'll be thrown out on their ass regardless of whether or not a procedure is in place; I believe this has happened once already. > 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. The email addresses are appropriate for conducting Debian business. The machine accounts are required for debugging, scripting, hosting, what have you. It's a real community, neh? Look at all the stuff on people.debian.org, and all the really essential scripts elsewhere that started out in somebody's $HOME because they thought others might find it useful. I think almost everything started that way, but I haven't been around for a real long time. As for the accounts, they're needed for uploading. If you think that the DAM not explaining to every applicant (in great detail) exactly what is going on is a result of a lack of time, can you imagine what it would be like if there were only a few dozen people (trusted by everybody) who could upload? Heck, just the infrastructure required for that scale of sponsorship is mind-boggling.
Attachment:
pgptdhkROIVy6.pgp
Description: PGP signature