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

Russ Allbery rra at
Wed Jul 24 12:15:01 EDT 2002

Booker C Bense <bbense at> writes:

> - 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.

I agree with Booker here in that I think it definitely requires work,
although I'm perhaps a bit more optimistic about how much work it
requires.  I simply don't see much alternative.  We need them and we'll
have to maintain them one way or another.  I don't expect to see the world
in which we can replace them all with ssh any time soon, particularly
given the security problems that are plaguing ssh implementations.

> - I think that forking off the appl tree would help here as well.  From
> what I've seen in the past MIT has been extremely relucant to give
> people cvs access to the tree. I think the reasons for this are all
> understandable. However, if the code tree was a seperate project with a
> seperate archive then I think it would be easier for 3rd parties to
> contribute. I doubt MIT has the "monkeys" to support these apps, I doubt
> any single institution does. But with some code clean up and a good
> distributed model, I think there is enough support among the various
> shareholders to keep these apps in repair.

I know it would really be nice from our perspective to figure out vaguely
clean ways to do the things that we need to do (like support for users
without .klogin / .k5login files under certain circumstances, stuff like
that that isn't particularly clean but is important to a large percentage
of our user base) that could go into central CVS somewhere so that we
don't have to keep maintaining them as local patches and doing nasty
merges with every new release of Kerberos.  Even if we still have to
maintain all of that code, just not having to do merges would save a chunk
of time.

Russ Allbery (rra at             <>

More information about the krbdev mailing list