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

[Donn Cave]

Quoth "Booker C. Bense" <bbense at networking.stanford.edu>:
...
| - 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.

login.c is sure the file with the most changes of dubious value here
at the University of Washington central site.  But we don't use it
with rlogin or rsh, as we don't support those applications, so if
telnetd moved away from login.krb5, we wouldn't have any need for it.
Our changes include a reported bug fix or two, but are mainly either
about accommodating perversities of AIX, or local policy support that
could reasonably be parameterized as configuration options.  I wouldn't
write it off as hopeless.

I would be really interested in an organization direction that would
not just maintain the stuff that MIT has been releasing, but also
help the available Kerberos software grow to the point where we could
really use it.  At my site, I'm sorry to say we fall far short of the
potential of Kerberos as a single login system, because of missing
applications (like HTTP), missing utilities (like screen savers), and
unsatisfactory or expensive software (like anything for Windows operating
systems.)  If we were to shut down our Kerberos applications, the only
people on campus who would really miss them are MacOS users who need
Fetch, plus a handful of people out of 70K who understand it well enough
to object on principle.  To just maintain these applications is to insure
their irrelevance.  We need to fill some holes.

There is some important external software, like Fetch or imapd, but
I think a kerberos.org could do a lot for those too - web links to
them, documentation of Kerberos features like krb5_kuserok() and
krb5.conf options, approving standard implementation policies.

	Donn Cave, University Computing Services, University of Washington
	donn at u.washington.edu