Is anyone or a group of people able to maintain appl/bsd better than MIT
Nicolas.Williams at ubsw.com
Tue Jul 23 15:40:00 EDT 2002
On Tue, Jul 23, 2002 at 11:53:10AM -0700, Booker C. Bense wrote:
> - 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.
> - Booker C. Bense
Yes, login.krb5 is a mess. I tried to configure telnetd to support
the native /bin/login - the code is almost all there for this, but
it just doesn't work; trying to fix it led me down an ugly alley that
made me want to rewrite the relevant code from scratch (I haven't had
time to revisit this - if and when I patch this I'll file a bug report).
Krsh is simpler, much simpler, and would be simpler still if krb4
support were dropped altogether, and krcmd() would be simpler still if
the stderr channel were multiplexed onto the one connection initiated
by the client - to hell with the fact that the old rcmd() didn't work
that way. But then, this stuff grew up from BSD source.
I think we're proving that supporting these apps is a whole different
job than developing and supporting the libraries/utilities/KDC/kadmin.
SSHv2 w/ ext-keyex-gss is really tantalizing. In fact, I'm more
familiar with the OpenSSH source and Simon Wilkinson's GSS patches
for it than I am familiar with the MIT applications, so I've been
rather happy with OpenSSH w/ GSS. There are already two (related?)
implementations of SSHv2 w/ ext-keyex-gss that I know of (OpenSSH w/
Simon's patches and Kermit 95) - besides these I imagine that adding
GSS support to the Perl5 SSHv2 implementation floating around wouldn't
be hard; three implementations would be great.
Unfortunately a number of Windows apps out there are starting to
support kerberized telnet (e.g., eXceed, Reflection X/MultiHost)
or already do, but they generally don't support kerberized protocols
other than TELNET/FTP (Reflection X supports external app-launching
mechanisms in a way that allows one to plug-in most SSH implementations
for Windows - dunno about eXceed). So Kerberized telnet is here to stay,
at least for some time.
So what would be the scope of kerberos.org?
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-
Visit our website at http://www.ubswarburg.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
More information about the krbdev