Comments on the rlogin/kcmd thread
hartmans at MIT.EDU
Thu Aug 8 21:57:01 EDT 2002
>>>>> "Darren" == Darren Reed (Optimation) <darrenr at optimation.com.au> writes:
>> - It's nice to have the sample applications in there to test
>> and make sure the basic functionality is working, plus it
>> establishes a "base line" functionality requirement, especially
>> for vendors.
Darren> Definately! This last point cannot be understated. It is
Darren> one thing for kinit to work, but when you can "telnet -x
Darren> remote" and not need to enter the password again, you have
Darren> that much more confidence in it all working.
No actually when I type telnet and I get something other than command
not found, I have confidence that either I'm dealing with old
mainframes or that my system is misconfigured and someone has
installed an insecure access application. Seriously, there ar
good reasons to use rlogin (simpler, less published security issues)
but for accessing Unix systems there are no reasons to use telnet.
It's limitid to 56-bit DES and an alarming number of implementations
still have downgrade attacks.
Darren> the development and maintenance of these is to be split of
Darren> separately, does this rule out shipping them independaly
Darren> when it comes time to say: "Here's release X..Y of MIT
Darren> Kerberos" ?
Yes, that would be the result. I see the following problems keeping
them in the tree but having external maintainers:
* We'd have the choice of shipping broken insecure software or making
a new release of MIT Kerberos when application security problems are
discovered. One of the things we want to accomplish is to avoid
having to do a release of Kerberos for all three platforms (Windows,
Mac and Unix) just because there is a security problem in a
* If we're going to ship in the release, we'd want to track bugs and
deal with packaging issues. That's something we don't think we need
to do if it is externally maintained. BUt also, I don't think it is
in the best interest of people taking our release and packaging it
or integrating it for a site. I'd sort of hope those people would
want to take the latest release of bsd/telnet/ftp rather than what
we happen to ship at the time. So why would it benefit us to
confuse them by providing two versions. As I've said we're
optimizing our releases for vendors and site integration not for end
One member of the team has suggested establishing something like
afscontrib along side our release area. I don't think this option
would bother us much, but I'm not yet convinced it would be such a
great idea. First, we get enough complaints about how hard it is to
download Kerberos that I cannot imagine someone else wanting to use
our download process. Secondly I never really was impressed with
afscontrib. Did it really actually make it easier for people or was
it just another place software went to bitrot?
More information about the krbdev