Date: Fri, 16 Feb 2001 15:09:42 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.ORG> To: Matt Dillon <dillon@earth.backplane.com> Cc: "Young, Jason" <Jason.Young@anheuser-busch.com>, Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca>, Dag-Erling Smorgrav <des@ofug.org>, Mark Murray <mark@grondar.za>, arch@FreeBSD.ORG Subject: Re: 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: <Pine.NEB.3.96L.1010216150200.59690A-100000@fledge.watson.org> In-Reply-To: <200102161935.f1GJZtO02394@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 16 Feb 2001, Matt Dillon wrote: > I think it's worth putting together a comprehensive list of modules > and assign a 'controversy level' to each one. Sure, one could argue > over > the assignments, but it will still be a good road map. It's > important > to keep the base system as modernized as possible. In many > respects, we > bear the responsibility to push our commercial and non-commercial > users > towards more reasonable configurations for today's interconnected > world. I'll reiterate the point just to make sure it didn't get lost in the previous e-mail: Some software relies on tight integration with the base operating system to work correctly. This includes any software tied into our authentication and login systems. This is in part due to our inability to provide clean abstractions for these services. Pushing this software out of the base system will result in far less security for those who use the software, and have negligible security benefit for those that do not use the software. Moving towards a fine-grained install and more careful build knob definition can give both of these sets of users warm fuzzies. Or let's put it this way: suppose we stop maintaing an FTP daemon on FreeBSD. Now all FreeBSD users who want to use an FTP daemon have to fall back on third party software. They might install the NetBSD or OpenBSD FTP daemon, or maybe wuftp or proftpd. Only it turns out that our FTP daemon has had far fewer security problems than any of those alternatives, because we did a pretty successful preemptive code audit on it. So we've gone from having a well-integrated piece of software that understands out login.conf class concepts, and meets some pretty riorous standards for software safety, to bumping users to third party tools with known deficiencies. We provide a fairly complete operating system, with well-integrated components and version control. There are some areas where there are particular well-maintained third party packages where doing the work ourselves makes little sense, and not much local adaptation is required (XFree86, Apache, etc), but there are a lot of pieces of software where we have substantial local adaptation and high levels of integration. This is a benefit. Let's not strip our system down to a bare minimum kernel and libc, and lose that level of integration. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services 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?Pine.NEB.3.96L.1010216150200.59690A-100000>