Re: Excessive wait for DAM - something needs to be done
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
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
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
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.
firstname.lastname@example.org | An ounce of perception,
http://www.debian.org | a pound of obscure...