Date: Sat, 19 Jun 1999 07:57:56 -0500 (CDT) From: Joe Greco <jgreco@ns.sol.net> To: des@flood.ping.uio.no (Dag-Erling Smorgrav) Cc: security@freebsd.org Subject: Re: make world clobbers (was Re: some nice advice...) Message-ID: <199906191257.HAA50422@aurora.sol.net> In-Reply-To: <xzp1zf89xo3.fsf@flood.ping.uio.no> from Dag-Erling Smorgrav at "Jun 19, 1999 2:34:20 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> Joe Greco <jgreco@ns.sol.net> writes: > > Any server application, be it sendmail, named, ntpd, apache, squid, etc etc > > etc., needs to be compiled fresh from the vendor. > > That is complete bullshit. By doing this, you are *introducing* > problems rather than solving them. The FreeBSD developers spend a lot > of effort fixing bugs, plugging security holes, and adapting software > to run optimally on FreeBSD. You shouldn't hand-roll things like > sendmail or BIND unless you're prepared to spend a *lot* of time > duplicating their work, and making sure you got it right and didn't > introduce any bugs of your own in the process. Any FreeBSD developer who spends a lot of effort fixing bugs and plugging security holes without rolling the changes back to the vendor is an idiot and a fool. That would be the "complete bullshit" that you refer to. FreeBSD has a long history of staying a rev or two out-of-date with respect to integrated packages such as Sendmail or BIND. That's fine for the average user, but doesn't cut it in heavy production environments where you often need different compile-time option definitions _anyways_. By keeping the idea of OS and application separate, you make it all that much easier to keep your software up to date and your system secure. This isn't just a FreeBSD thing; it is good policy on _any_ platform (think about something like Solaris for example). When you are doing this professionally for a client and are faced with a client who wants you to make DNS/mail servers out of (1) a Solaris box, (2) an old SGI, and (3) a FreeBSD or Linux box, you can either accept the current lame software that is installed on each and the headaches/dysfunctionality associated, or you can level the playing field and do the professional thing, and tune each of the installs for the client's needs at the same time. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199906191257.HAA50422>