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

[Booker C. Bense]

On Wed, 24 Jul 2002, Darren Reed (Optimation) wrote:

> From: "Sam Hartman" <hartmans at mit.edu>

> > MIT has significant experience with producing useful technology, but
> > not doing a good enough packaging job that others feel the need to
> > take over the packaging.  All this experience is bad: we tended to get
> > multiple versions, incompatibility, API/feature set divergence, and
> > failure to fix bugs in all versions.
>
> I don't quite get how packaging fits in here unless you mean it isn't
> straight forward to build an RPM out of the Kerberos .tar.gz source
> code.  (for example)

- What he means is packaging in terms of src code maintainance. What
if for some bizarre reason you have to sick with a certain release
of klogind, you don't get back patches. Also, there is significant
blurring of the lines between public/private apis in some parts of
the code. All these issues have improved with time, but there is
still room for improvement.


>
> > It seems that if we do decide to drop appl/bsd, we should treat it
> > like the other applications and find something to recommend in its
> > place that is compatible.
>
> This is a serious problem.  I view the set of programs inside of
> appl/bsd as being guaranteed to work with MIT Kerberos.  If
> you go out to 3rd parties for these tools then you lose some
> level of assurance that it will "just work".
>

- This is directly related to the packaging issue above. If you
standardize and document the API, then it all should "just work".
The incompatiblity problems that plague kerberos are precisely
because the apps and the library are not seperated. IMHO having
the library seperate would encourage 3rd party apps, since it
would provide some internal discipline and remove a lot of the
fuzziness about which api's are supported and which aren't.


> > Currently MIT is providing critical bug fixing services for these
> > applications and is doing fairly little else to them.
> >
> > Are there any individuals or groups of people out there who believe
> > they could do a better job and would be willing to try?
>
> In all honesty, how much work needs to be done on them?

- LOTS. They desperately need PAM support. The problem isn't so
much the bsd deamons themselves but login.c which they all require.
If you could get rid of the requirement for login.krb they would
be much simpler to support. Supporting login.krb requires an intimate
knowledge of the underlying OS and took more that 50 percent of the
time I did "kerberos programmning."

> Is the protocol used by rlogin/rsh/rcp going to change in the
> next 12 months in such a substantial way that they are going
> to need to be written 5 times ?  (exageration)

- No, but I expect to see that many changes to the underlying OS's
that you have to support. Solaris 9, new linux version, AIX,
and god knows what will come out of the HP/Compaq merger.
Login deals with all the nasty dirty bits that are always
vendor specific. Look at all the code just to get the stupid
wtmp/utmp entries right.

>
> In comparison to ftp and telnet, which do seem to be evolving
> still, the others appear to be fairly static but it sounds like you
> are short on "monkeys" to turn the wheels...
>

- I notice that none of the people claiming that the bsd deamons
need "little or no maintaince" have worked on the code in there.
I've spent a lot of time in there over the last year and it's
not maintainable in a casual fashion.

> You are already using CVS for development of MIT Kerberos,
> I hope, and rather than split these out of the "official" Kerberos
> distribution, maybe the team of responsible parties needs to expand
> with some extra parties taking on "official" responsibilities for
> subsections of the Kerberos tree.  Is this sort of thing attractive
> to the core group of people working on MIT Kerberos ?  I would
> put up my hand to help here if this was workable (heck, I would
> help out if appl/bsd were separated but I'd *really* like us to
> find a solution that doesn't require that.)
>

- I think that forking off the appl tree would help here as well.