Date: Fri, 16 Feb 2001 13:10:42 -0700 From: Lyndon Nerenberg <lyndon@orthanc.ab.ca> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: arch@FreeBSD.ORG Subject: Re: List of things to move from main tree to ports (was Re: Wish List (was: Re: The /usr/bin/games bikeshed again)) Message-ID: <200102162010.f1GKAgq40421@orthanc.ab.ca> In-Reply-To: Your message of "Fri, 16 Feb 2001 13:02:27 EST." <Pine.NEB.3.96L.1010216125203.57795C-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> "Robert" == Robert Watson <rwatson@FreeBSD.ORG> writes:
Robert> do run Kerberos will suffer a great deal. My hope would
Robert> be that we'd keep supporting KerberosIV through the end of
Robert> the 4.x branch, and make KerberosV be the supported
Robert> Kerberos on 5.0-RELEASE, and have KerberosIV be a port.
If there is a move to K5 for 5.x I think it's imperative that the
implementation fully support an existing deployed K4 infrastructure.
E.g. we use K4 everywhere in our shop. One of the critical applications
is kcvs. If the 5.x cvs cannot do kserver within our deployed K4
infrastucture, 5.x will not be running on our infrastructure machines,
period. The same applies to a lesser extent with the kernerized r*
utilities. (And yes, we're about to deploy a testbed to start looking
at these interoperability issues.) K4 is going to be around for
quite a while (at least on the client side), and can't be ignored.
Robert> One strong argument for disabling aspects of less well
Robert> maintained code in the base system is whether they
Robert> constitute a security risk by existing there unused.
The issue here is the definition of "unused." I'm sure there are
things in the base that get used a _lot_ less than UUCP, and which
aren't being considered for removal. With UUCP in particular, we have
to be *very* careful not to let our first-world everyone-has-a-t1 view
of the world blind us to the reality that large parts of the planet do
not have ubiquitous and cheap IP connectivity. UUCP still provides a
lot of connectivity. And I think the arguments against keeping UUCP
are primarily FUD. I keep hearing about the security problems, but
I've yet to see anyone document them. If the issue with UUCP _really_
_is_ security, let's audit the code. Just throwing it out doesn't
serve any useful purpose.
--lyndon
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102162010.f1GKAgq40421>