Date: Wed, 28 Feb 1996 17:22:50 -0500 From: eichin@cygnus.com To: hobbit@avian.org Cc: freebsd-bugs@freefall.freebsd.org, problems@bsdi.com Subject: Re: Kerberos 4 rsh/rcp fixes Message-ID: <199602282224.OAA20615@freefall.freebsd.org> In-Reply-To: <199602281956.OAA14421@narq.avian.org> (message from *Hobbit* on Wed, 28 Feb 1996 14:56:41 -0500)
next in thread | previous in thread | raw e-mail | index | archive | help
> it seems appropriate that other release tree fixes could be made at the same > time before new "official" releases go out. You're about a week and a half late for that... we prefer our customers learn about problems from us *before* the read about them in the Wall Street Journal :-) >README >is a later release of October 1995 or so. Despite my signed affidavit of U.S. >citizenship existing in their records as they require, repeated efforts to >obtain the updated release from Cygnus have failed. I don't (and never have) deal with the faxed signatures directly, but this is still odd, since many people have succeeded in getting new releases. We *have* recently changed policy to permit people to send us a copy of the original email we sent listing the hidden path to some previous release in order to get the newest one, which should make it easier if you have the old mail. >indications as to what the latter port should *be*. While initially trying to >get things working, Rob Austein off the cuff assigned it to TCP 2106, or one I thought there was some convention about not using even-numbered ports, though I can't recall what the logic was; it may only apply to low-numbered ports, and may be a BSD convention anyhow. >Which brings us to the major "rcp" problem. Cygnus decided to invent their own >protocol for "rcp" rather than fix encrypted "rsh" and make "rcp" able to talk You're confused. Cygnus simply made our code implement *exactly* what the MIT code did. Really, it would have been ludicrous to invent an rcp encryption system that *only* differed from rlogin by the padding order... it's just that they were written by different undergrads who didn't communicate :-) It wasn't until we tried to unify the code through the kstream library that we found that problem... >> CNS release is still portable across more >> operating systems than the KrbIV/BSD code, but the way they get there is messy >> and clearly ill-maintained. You don't defend that at all, though most of the rest of your analysis is fairly solid... there is a reason we're using autoconf for krb5, of course :-) However: >> I also had to deal with their rather cavalier way >> of inventing standards. is patently untrue. We've always maintained the the MIT release was standard, and preserved compatibility with it, at some cost... see the rcp complexity above, or the fact that rsh still uses a stderr back channel, or the *really* gross error-checking hack for encrypted rlogin, which causes you to actually see server side errors (instead of "rcmd failed") *without* changing the protocol. Again, much of your analysis about the existing V4 code base is quite accurate; the exceptions, however, are glaring... _Mark_ <eichin@cygnus.com> Cygnus Support Cygnus Network Security <network-security@cygnus.com> http://www.cygnus.com/data/cns/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602282224.OAA20615>