[Buildbot-devel] Re: [Python-Dev] buildbot

["Martin v. Löwis"]

Brian Warner wrote:
> This makes it much easier to implement things like the "Force Build" 
> button, and allows the same status-retrieving API to be used by all 
> the different status-delivery modules: web, IRC, email, PB.

Certainly: I can easily believe that this is easier from a development
point of view.

I can also accept that this is the only way if you want to trigger
things through the Web (such as the Force Build interface). However,
this interface was the first thing I turned off, because there is
too much potential for abuse. The slaves are (in our case) donated
resources, sometimes in machines that also serve other purposes.
The donors need to know what precisely will run on their machines,
and when precisely that will happen, so "Force build" is disabled.

The reason I want static pages is for security concerns. It is not
easy whether buildbot can be trusted to have no security flaws,
which might allow people to start new processes on the master,
or (perhaps worse) on any of the slaves.

I know I could limit the Twisted webserver to localhost using
firewalling/iptables (and I will need to if there is no other
option); just having it generate static pages would have been
more convenient.

BTW, the same security concern applies to the IRC listener
and the slave listeners: how do I know that nobody can take
over my infrastructure using carefully-crafted messages?

I could study the entire protocol stack to convince myself,
but I would prefer if there was an easy answer, like:
this is the set of operations callable through twisted,
and these are the preconditions for calling them.
For the IRC, this is easy to see (just inspect all
command_ procedures), but what about the slaves port?

> It's not the greatest solution, but it might let you add more 
> Builders without making the display unworkably complex.

Thanks! so far, we only have 8 lanes, which is still managable. If size
increases, I come back to these ideas.

Regards,
Martin