[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bits (Nybbles?) from the Vancouver release team meeting

* Steve Langasek (vorlon@debian.org) wrote:
> On Mon, Mar 14, 2005 at 11:41:59AM +0000, Steve McIntyre wrote:
> > When you say "N+1" buildds for a release architecture, do you mean
> > _exactly_ N+1, or _at least_ N+1?
> At least; although, there are some concerns about plugging too many machines
> into wanna-build for each arch, both for scalability reasons (hopefully
> addressed once we have connection caching support on newraff) and, I
> suspect, for  security reasons (since the thinner we spread our autobuilder
> network, the more danger there is, statistically, of a trojan being
> injected), so it may be that in most cases no more than N+1 would actually
> be allowed at any one time.

The scalability reasons are technical problems that I'd like to think
the Debian community would be happy to step up and try to help with.
I'm personally interested in this and I know others have even worked on
a complete rewrite of wanna-build.

I understand the security concerns but I don't agree with them.  If you
want some statistics about trojans consider the size of our developer 
base, the fact that anyone can upload binary packages for any
architecture and that there's no check that an uploaded source matches
the uploaded binary.  In general I think buildd maintainers and local
admins should be vetted and trusted, either by having them be DDs
themselves or through some other process.  It would be possible to
reduce the abilities of a buildd too- a simple example would be that
buildds can only upload binary packages for the architecture they're
understood to be building for, and none of them can upload arch all
packages.  This should at least reduce the number of people affected by
a buildd upload being trojaned dramatically through the simple fact that
most uploads are i386 by DDs and most users are using i386.

> The partial answer I was given for this was to wait and see how well
> ftp-master scales once connection caching is in place, before committing to
> giving porters free reign to plug new autobuilders into the network.

I'm not a big fan of waiting around to see if a stop-gap measure helps.
I'll certainly be happy if it means that ftp-master can support (3
buildds x 3 dists x 11 archs) 99 buildds but I'm afraid in the end it's
not going to be enough to allow more than 3 buildds per arch and as many
archs we have now and as many as would like to join.


Attachment: signature.asc
Description: Digital signature

Reply to: