Comments on the rlogin/kcmd thread

[Sam Hartman]

>>>>> "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> If
    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
  UNix-specific application.

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

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?


--Sam