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

Re: Unofficial buildd network has been shut down

On Wed, 01 Sep 2004, Goswin von Brederlow wrote:
> If it were personal and Debian had reasons not to trust me that would
> be OK (well, not for me but in general) but it's not. Its worse. DDs

IMHO that's "better", not "worse".  Such decisions are not to be made
because someone important does not like you personally.  So, the fact that
it was not "personal" is "good".

> are not allowed to think for themself and decide whom and what systems
> to trust. That was the message conveyed in the thread and on irc. Its
> not the place of a DD to decide for all of Debian whom to trust.

Obviously.  And from a security standpoint, that is the only sane position.
Trust is not, and cannot be transitory.  This is basic, and it is
acknowledged even on the most informal security model in existance: "a
secret stops being a secret if you tell it to anyone else/keep secrets to

We should act as a whole on security matters.  If we decide that "third
party run" autobuilders are okay (for some definition of third party), then
they are okay for *everyone*.  Otherwise, they must "not be okay" for
anyone, or any security implications are being thrown out the window.

> And with that I consider the matter closed.

Pehaps.  But we can try to address the real issue behind the matter, which
is not one of trust, but one of a perceived need for more autobuilders.

We could, for example, try to:

  1. Create a "NM" (really, new porter) process directed at buildd managers
     and porters.  We already have one for maintainers, and one for
     documentation writers.
  2. Go ahead with the idea of roles in debian.  A "builder/porter" would
     need to have as much trust as a "package maintainer", since the
     security implications are about the same.  The social implications are
     not the same, if the builder can stay quiet while wearing his Debian
     hat (or they are the same if not).  Theorically, a builder has much
     less contact with the users than a package maintainer.  The set of
     skills is a bit different, as well.
     (1) is a suggestion on how to accept new people for (2), but not the
     only possible way.
  3. Start beefing up the team that takes care of the autobuilders as a
     whole, so that we can easily beef up the number of autobuilder machines
     for each arch on those that cannot keep up with i386 (I expect that in
     one year or two, the lead arch will change, and i386 will need to have
     two or more autobuilders to keep up :) ), AND THE NUMBER OF BUILDD

     (3) needs acceptable volunteers, whatever that means.  And hardware
     with an acceptable administration profile, which I am not sure if it is
     a problem right now or not.

IMHO it is clear that it would be a good goal to have at least two active
people responsible for any given arch (with access to *all* autobuilders for
that arch, so that a set of packages does not get stranted because they were
built, but there is no one with access to sign and upload them).  And that
we have a reasonable number of people doing this as a whole (certainly more
than two!) and for the common build infrastructure, for the same reasons.
More resiliency is good.  Workload sharing is good.

  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Reply to: