telnet & ftp official status

Mike Patnode mike.patnode at centrify.com
Wed Oct 1 14:03:44 EDT 2008


We also have added a number of fixes to the these utilities as well as
the core API.   Our changes are against the 1.4.3 source base:

  Valgrind/Coverity fixes
  Referral Processing (client side only)
  Force TCP configuration
  Credentials from skey: krb5_get_init_creds_skey()
  Malloc/Free API for key creation APIs (allow encryption keys to be
kept in mlock'd memory)
  Microsoft S4U extension implementation (client side only)
  ftp/telnet PAM/LAM support
  AIX port
  Salt retrieval API

We also have implemented a secure service name canonicalization
mechanism, but since it's Active Directory specific, I don't think it's
generally useful to other folks.

I'd like to get as many of these changes back into the distribution as
possible (with the complete understanding that some may not be
included).   I know the Consortium recently purchased Coverity, and our
fixes could certainly save quite a bit of time there.  We've analyzed
and fixed about 200 items identified by Coverity in just the libraries
and clients.

So the question is, what's the best way to deliver these changes back
upstream?  I suppose we need to follow the formal proposal process for
the API and feature changes.   The question is do you want the diffs for
the Coverity & Valgrind issues against the 1.4.3 base, or do you just
want to wait until we do our 1.6 port?

mp

-----Original Message-----
From: Russ Allbery [mailto:rra at stanford.edu] 
Sent: Tuesday, September 30, 2008 2:11 PM
To: Tom Yu
Cc: Mike Patnode; MIT Kerberos Dev List
Subject: Re: telnet & ftp official status

Tom Yu <tlyu at mit.edu> writes:

> We need volunteers to maintain the applications if we are to remove
them
> from the main distribution.  Russ Allbery has expressed a willingness
to
> do so in the past.  Russ, are you still willing to do this?  Is anyone
> else willing to help out?

I'm still willing to help maintain Kerberos rlogin, rsh, and rcp.  I
think
they're simpler and easier to maintain than ssh, and they're also
less-well-known and therefore not as much of an attack target.  It may
be
that I'll slowly change my mind and eventually switch entirely to using
ssh, particularly given the firewall issues with the rsh protocol, but I
still find them convenient.

However, I have very limited amounts of time to look after them (for
example, I've not managed to do more than read through the patches for
PAM
support).  So while I'm willing to help, I'm not sure how much time I'll
realistically have and how much work I'll be able to put into them.

I have no personal interest in Kerberos telnet or ftp.  We never used
Kerberos ftp at Stanford and haven't used Kerberos telnet in years.  I'm
happy to help generally support a build infrastructure including those,
but won't have any time to make code changes in those applications in
particular.

I'm separately strongly interested in making sure ksu continues to be
available and works, although I know it's not part of the apps tree and
is
something of a separate issue.

-- 
Russ Allbery (rra at stanford.edu)
<http://www.eyrie.org/~eagle/>




More information about the krbdev mailing list