[BusyBox] Improving Our Development Process

[Mark Whitley]

On Tue, Jan 23, 2001 at 05:32:38PM -0600, David Douthitt wrote:
> 
> On 23 Jan 2001, at 22:11, Mark Whitley wrote:
> 
> > Okay, gang, the time has come for an explanation about the whole netkit-tiny
> > seperation plan:
> > 
> > There were a few reasons offered originally, like being able to
> > suid netkit-tiny while not having to do the same for busybox, but
> > Alex makes the very good point that we could simply build two
> > executables from the same codebase. 
> 
> I've been wondering if building two sets of tinylogin would be 
> advantageous - one suid and one not.  Seems like it would be more 
> secure..... right?

Yes, as I mentioned, the original reason offered for the split was so you
could suid the network-apps binary (i.e. netkit-tiny), but leave the
shell-apps binary (i.e. busybox) non-setuid. As Alex mentioned earlier,
though, this can be done even with the existing, single codebase, just by
building two seperate binaries with two different Config.h files.

> > Alex (and others before him) futher make a good point that
> > splitting up the apps would cause some redundancy in shared code
> > (i.e. utility.c) which could lead to further maintenance burdens
> > (somebody fixes a bug in busybox utility.c, but doesn't fix it in
> > netkit-tiny utility.c, etc.). One could also argue that the applets
> > should be kept together so people using it can decide for
> > themselves what they want to compile into however many executables
> > they want. 
> 
> Why not use a dynamic busybox library?  Convert this utility.c into 
> busybox.lib.so ...and it wouldn't be far from there to go to 
> busybox.lib.a ...

This is certainly one approach. The thing I dislike about this approach is
that it complicates development by adding an additional dependency. It also
makes debugging a little more involved.

We have bandied about the idea of makinga libbusybox and there could possibly
be some merit to it.

> > In short, there is no technical reason why networking apps *can't*
> > stay in busybox, and in fact there are some pretty good reasons for
> > keeping all the applets in one codebase. 
> 
> What about the suid v. non-suid split?  Doesn't this enhance 
> security?1

Addressed above.

> > I went and asked Erik about this (seeing as how he sits right next
> > to me and isn't on the road this week), and he said that the
> > biggest reason for splitting up busybox is to make life a little
> > easier on him, cuz maintaining busybox is a big job, one that
> > consumes a lot of his time (and he already has a full-time job). 
> 
> What about tinylogin?

At this point, tinylogin is essentially a "finished" product and consumes very
little of Erik's (or my, or anybody else's) time.

uClibc on the other hand...

> > If anyone has any further ideas on how we can "spread the load" a
> > little better, please propose it. If everyone else can help
> > shoulder the burden just a little bit, Erik's shoulders will feel a
> > lot lighter. :-) 
> 
> What if we went the library route?  A busybox library could even be 
> split off from the applications.

It could, but the question then becomes: Who becomes the maintainer of said
library? What will be the process of moving common code from codebase X, Y, or
Z into the library. If you'd like to make the case for the library (spell out
hte list of advantages), please do, but personally I don't know if it would be
an overall win. I can be persuaded otherwise, but right now I'm leaning away
from the library approach.

Mark Whitley
markw at lineo.com