Re: Work-needing packages report for Jul 11, 2003

[Matthew Garrett <mgarrett@chiark.greenend.org.uk>]

Jamin W. Collins wrote:
>On Sun, Jul 20, 2003 at 10:51:56PM +0100, Matthew Garrett wrote:
>> Someone who enters Debian is in a position to upload a package that
>> could backdoor a very large number of machines. Attention to detail at
>> the DAM stage is *more* important than pretty much any other decision
>> making process in Debian. If the DAM fucks up even once, we lose
>> massively.
>
>There's that paranoia spectre again.  There is nothing that stops a
>current DD from doing the exact same thing.  There is also nothing to
>indicate that the above is DAM's reasoning for the extremely long
>delays.  If an applicant isn't clearly trustworthy within 60-90 days is
>another 9 months or more truly going to help?  It would be better (and
>safer according to your argument) to refuse the application and let them
>reapply later, or even state that as a reason for having the applicant
>wait a longer period.  Instead we simply leave the applicant in limbo
>without any update.

No, that's not what I said. Please go back and read it again.

There is nothing that stops a current DD from uploading a malicious
package, true. People could betray the trust that is held in them. Part
of the reason that this hasn't happened is that we've only let people
into Debian if they're trusted, and so should continue to do so.

As for paranoia - yes, of course. Debian should be paranoid. Insanely
so. If one single person uploaded a trojaned package just before a
freeze and got it into a release without anyone spotting (and look at
how long it took for the micq issue to be spotted), the project would be
*dead*. People trust Debian, but that trust can only be justified if the
developers themselves can be trusted.

>> Is anyone appropriate for the task currently volunteering to do so?
>
>Just because people aren't beating down the door to volunteer doesn't
>mean there isn't someone that would accept the job and do a
>significantly better job then the current one.  Hell, the position isn't
>even open so I would hazard a guess that most people aren't volunteering
>for it becuase it's listed as filled.

Anyone actually qualified to fill the role should be aware of this
discussion, and well able to voice their willingness to be involved.

>> We occasionally bitch about the length of time it takes the security
>> team to produce an update for certain things, but it seems to be
>> generally understood that it's taking that long because that's how
>> long it takes. Without potentially compromising the entire project,
>> I'm unconvinced that the DAM process could be made significantly
>> faster.
>
>I doubt the security team is as unresponsive as the current DAM.
>Release of information/explainations have a way of creating
>understanding.  The current DAM has release no information or
>explaination for the current state of affairs, and based on past
>performance isn't likely to.

That's something that should be rectified, but it's not necessarily
something that the DAM has to do. Creating a document describing the
DAM's roles and responibilities and what he actually does during the DAM
approval stage is not a dreadfully difficult task, and would be a good
project for somebody to work on. This (and associated) thread ought to
be a reasonable starting point.

-- 
Matthew Garrett | mjg59-chiark.mail.debian.devel@srcf.ucam.org