Date: Tue, 20 Feb 2001 13:59:43 -0700 From: Lyndon Nerenberg <lyndon@orthanc.ab.ca> To: Matt Dillon <dillon@earth.backplane.com> Cc: arch@freebsd.org Subject: Re: Summary of List of things to move from main tree to ports Message-ID: <200102202059.f1KKxhq64452@orthanc.ab.ca> In-Reply-To: Your message of "Fri, 16 Feb 2001 23:22:17 PST." <200102170722.f1H7MHm20405@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> "Matt" == Matt Dillon <dillon@earth.backplane.com> writes:
Matt> Robert Watson suggests, and others agree that the best
Matt> way to handle UUCP is to change the NO_UUCP make.conf option
Matt> into a BUILD_UUCP make.conf option. I would interject that,
Matt> in addition to that, we should not create the uucp directory
Matt> hierarchy unless uucp is selected in make.conf (i.e. not
Matt> create /var/spool/uucppublic, a directory which defaults to
Matt> modes 777, by default).
Even if you do install UUCP, there's no requirement for this
directory to exist.
Matt> Robert Watson also makes the point
Matt> about the suid/sgid nature of many uucp binaries, and I and
Matt> others will attest to the fact that UUCP is simply not
Matt> maintained anymore. That is a dangerous combination to have
Matt> installed in the system by default.
So if a maintainer is found there is no longer a reason to remove
UUCP from the base, yes?
Matt> Despite Terry's waxing poetic about
Matt> UUCP's dialup capabilities, every soul I know (except maybe
Matt> Terry) who has ever used UUCP in the past no longer does
Matt> (and I should know: I wrote AmigaUUCP!).
I use it. Constantly. Over dialup and TCP. As do a number of sites
I'm affiliated with.
Matt> However, if those
Matt> people are going to make a big deal about it, I suppose we
Matt> can take the intermediate step of having a BUILD_UUCP
Matt> make.conf (opt-in) option for the next few years.
Hey, WE aren't making the big deal. YOU are the one talking about
yanking out a perfectly functional piece of the OS.
The justification for removing UUCP is stated to be:
It's not maintained, and it's full of security holes.
I'll agree with the first point. I'm not convinced of the second
(nor am I ruling it out).
Let me address the first point by stepping forward and volunteering
to be maintainer of the UUCP code. I've been using/debugging/enhancing
UUCP since 1985, so it's not a big deal.
Presuming that happens, I have ideas for addressing the second
point. E.g.: Much of the set[ug]uid-ness in UUCP can be eliminated by
using IPC mechanisms to communicate between the user-land commands and
the backend spooling system.
Well?
--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?200102202059.f1KKxhq64452>