From owner-freebsd-arch@FreeBSD.ORG Wed May 23 22:03:28 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9FDE116A41F; Wed, 23 May 2007 22:03:28 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 4325113C46C; Wed, 23 May 2007 22:03:28 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l4NM3PZb078740; Wed, 23 May 2007 16:03:25 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 23 May 2007 16:03:39 -0600 (MDT) Message-Id: <20070523.160339.-1264103850.imp@bsdimp.com> To: cperciva@freebsd.org From: "M. Warner Losh" In-Reply-To: <46546E16.9070707@freebsd.org> References: <46546E16.9070707@freebsd.org> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Wed, 23 May 2007 16:03:26 -0600 (MDT) Cc: freebsd-arch@freebsd.org Subject: Re: RFC: Removing file(1)+libmagic(3) from the base system X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2007 22:03:28 -0000 In message: <46546E16.9070707@freebsd.org> Colin Percival writes: : FreeBSD architects and file(1) maintainer, : : I'd like to remove file(1) and libmagic(3) from the FreeBSD base system : for the following reasons: : 1. I don't see it as being a necessary component of a UNIX-like operating : system. : 2. It's available in the ports tree. : 3. Due to its nature as a program which parses multiple data formats, it : poses an unusually high risk of having security problems in the future : (cf. ethereal/wireshark). : : The one redeeming feature of file/libmagic as far as security is concerned : is that it doesn't act as a daemon, i.e., other code or user intervention : is required for an attacker to exploit security issues. This is why I'm : asking here rather than wielding the "Security Officer can veto code which : he doesn't like" stick. :-) : : Can anyone make a strong argument for keeping this code in the base system? Because it is so darn useful, people use it in scripting all the time and it has been there for a long time. Warner