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
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
ADMINS FOR EACH ARCH.
(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