Is anyone or a group of people able to maintain appl/bsd better than MIT

[Booker C. Bense]

On Tue, 23 Jul 2002, Russ Allbery wrote:

> Derek Atkins <warlord at mit.edu> writes:
> > hartmans at MIT.EDU (Sam Hartman) writes:
>
> >> Currently MIT is providing critical bug fixing services for these
> >> applications and is doing fairly little else to them.
>
> > What else do you feel is required?  Critical bug-fixing in a simple
> > application that fits the needs of many users should suffice, no?  Is it
> > really much effort on the maintainer's part to keep these applications
> > in the tree and continue to distribute them?
>
> Amen.
>
> Furthermore, Stanford will continue to contribute patches to at least the
> BSD r* applications so that they will work in our environment, so it's not
> like MIT will have to do all the maintenance either.

- The problem here is that Stanford's environment is just different
enough so that some of these patches are useless if not downright
dangerous. BTW, you have much more faith in Stanford's IT to do the
right thing than I do. I guess that's why you're still there %-).

> I really don't think
> we'd do any better of a job at packaging than is already being done, plus
> I'm guessing we probably wouldn't want to take responsibility for the
> whole job, but we can certainly help keep them working.
>

- As the person who until very recently[1] was doing all this
"bug-fixing" at Stanford, I'd say most of it was an incredible waste
of time to support features of dubious value. I only did it because it
was a requirement to moving forward with actually deploying K5.
The appdefault stuff I did for kinit and login.krb probably has
some minor value for sites that are migrating from k4 to k5.

- In particular. login.krb is a HUGE mess, it is not maintainable in
it's current state. All of the bsd apps require that login.krb be
available. I made some attempts at refactoring it, but there is still
more work that needs to be done. IMHO, supporting these apps is not
just a matter of "simple maintainance". They aren't maintainable in
their current state. Unless you have somebody that's poking around in
the guts of them on a regular basis, it would take a significant
amount of time and effort to find and fix bugs in that code.

- I don't think you can make any statement about the state of the
security of this software by whether or not there have been any recent
vulnerablities published. People spent the hacking effort on the
programs with the biggest bank for the buck. I'd say you get at least
3 or 4 orders of magnitude more machines by finding a hole in sshd,
than you do by finding a hole in klogind. It's not that the holes
aren't there, there just isn't anybody looking for them.

- Booker C. Bense

[1]- I have changed jobs and am now working at SLAC.